Re: Savepoint

Hello Franck,

Flush failing is not the same as a rollback.  But I do see your point.  Continuing on would be very hard, some dirty bits cleared, others not etc.

One of the common cases would be a broken optimistic lock.  I suppose we could purge the broken record and re read it, hopefully keeping other records intact.  

In removeRecord        
  if ( ! hasSavepoint())  rinst.destroy(); 
is a bit dubious.  destroy() really takes on two meanings.  And what do we do about references to removed Record?

Would it be better to just clone the SRecordInstances and indeed the whole SDataSet?  Certainly fewer changes to the data structures.  More flexible, a little less controllable.  What was your reasoning?

And can we think of an elegant way to handle broken optimistic locks?  (Often it will just need to be thrown back to the user.)

(I'm pretty sure that all this goes beyond Hibernate when sessions are saved.)

Anthony

At 05:18 AM 5/08/2009, you wrote:
>  
>
>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, <mailto:berglas%40SpreadsheetDetective.com>[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: <mailto:berglas%40spreadsheetdetective.com>[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?"
>> 
>> 
>> 
>> 
>
>


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/