Re: Savepoint

Hello Anthony,

it is indeed something we need...

The use case is the following:

1) the user creates a dataSet and some records in the UI layer.

2) the dataSet is sent to the data access layer, where a session is
created and the dataSet is bound to it.

3) the flush fails for whatever reason, throwing an exception. Session
rollbacks. Thanks to savepoint, the dataset is NOT destroyed, it is
restored in the state it was when it came from the UI layer.

4) error are mapped to the fields, and the dataSet is sent back to the
user to allow corrections to be made

Right now (without savepoint), the dataSet is destroyed, and the user
input is lost, with a sorry error message...

Well, the truth is we could hold the user input in another data
structure in the UI, but our application is built around dataSet. So the
UI is build from the dataSet, either when reading from the database, or
when creating data...

We avoid the "sorry your input is lost" scenario by testing as much
failure case as we can before sending the dataSet to the data access
layer: we manually test the foreign keys for each record, we manually
test the unique constraints, etc... this is costly and not very
efficient. And sometimes it fails.

So having the ability to "rollback" a dataSet instead of destroying it
will really change our life...

Whether my code does the job remains to be seen :)

Does it make sense to you ?

Regards,
Franck


Le mardi 04 août 2009 à 20:04 +1000, [email protected] a
écrit :
>   
> Hello Franck,
> 
> Yipes. Is this something that you really needed? 
> 
> I'm guessing as a way to recover from broken optimistic locking. But
> that would not work -- there would be no way to correct the situation.
> 
> This sort of thing can lead to many issues, and needs thought. What is
> your use case?
> 
> We should probably take care that if a flush() fails, then unflushed
> records remain in a state that they can be flushed again. I have not
> looked, but should probably be the case already.
> 
> It should cost the same as clone(), as that it what it does. And maybe
> clone would be more useful?
> 
> I see you have a test case, have not had a chance to look at it
> carefully.
> 
> But what is your use case?
> 
> Let us put Map to bed with a test case, and then have a review of
> aggregate, before adding too many more features.
> 
> Regards,
> 
> Anthony
> 
> At 02:23 AM 3/08/2009, you wrote:
> > 
> >
> >Hi Anthony,
> >
> >I couldn't help but commit a new feature whose intent is to allow to
> >recover a dataset after a rollback, without the cost of the clone()
> >solution.
> >
> >If not used, the feature has no impact on the way simpleorm works, so
> I
> >thought it was quite harmful...
> >
> >I called it savepoint, and the usage is:
> >
> >ses.begin(ds.savepoint());
> >
> >then, if 'ds.hasSavepoint()', you can:
> >
> >ses.rollbackAndDetachDataset();
> >
> >The tradeoff is that ds.savepoint() is quite costly, especially for
> big
> >dataSets... (but should be less costly than clone()).
> >
> >Of course, comments are welcome !
> >
> >Franck
> >
> >
> 
> Spreadsheet Detective,
> Southern Cross Software Queensland Pty Limited
> 54 Gerler Street
> Bardon, Queensland 4065, Australia.
> 
> Email: [email protected]
> www.SpreadsheetDetective.com
> Ph: +61 427 830248 (Australian Eastern Standard Time)
> 
> "If the model seems correct only because the numbers look right, 
> then why build the model in the first place?"
> 
> 
> 
> 





------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/