Re: Detaching dataset on errors ABANDONED

Hello Franck,

I put several hours into this today, falling down one rat hole after 
another to get rollbackAndDetachDataSet to work.  And then Abandoned it.

The trouble is that there is a lot of state that changes during 
flush.  I set up a list of flushed records so that they could be put 
them back on dirty, which cascaded into other issues.  But then I 
realized that of course the optimistic values are also updated, and 
they would also need to be reset.  Not simple at all, so I abandoned it.

Then I started writing commitAndDetachDataSet_withoutFlushing.  But 
what awful semantics.  The bits that have been flushed are committed, 
the rest remain dirty in the dataset to be fixed up later.  Not good 
at all.  Abandoned.

The current approach is demonstrated in 
LongTransactionTest.rollbackDetachTest.  Just clone the dataset 
before attaching, and then fix the clone if necessary.  If you have 
deserialized the dataset you probably don't actually need to clone it 
at all, just reuse tbe bytes.   (My implementation of clone() cheats 
using serializable, a proper implementation would be good.)

Anthony


At 12:06 PM 10/08/2008, Anthony & Melissa Berglas wrote:
>Hello Franck,
>
>Hmm.   Semi consistent DataSets could get tricky.
>
>In particular, each flush removes the record from the update list, 
>one by one.  So if you were to successfully flush some records, then 
>fail and rollback, the dirtyness of the flushed records would be 
>lost.  When you eventually fixed the problem and committed, you 
>would loose the update.
>
>One approach would be to throw it back to the user (you).  Before 
>attaching the dataset, do an explicit query looking for duplicates.
>
>Another would be to copy the dataset before reattaching it.  Or at 
>least the update list.  Messy.
>
>Another would be to allow detachment without commitment, and just 
>let the user worry about it.
>
>Another would be to allow commit without flush.  So that any 
>partially made updates go through.  But that could also messy.
>
>
>What is the simplest?  Probably just allowing detach without commit 
>and lots of warnings in the docs.  Messy.
>
>I'll add session.unsafeDetachWithoutCommit.  (The required test 
>cases will be a bit tricky to set up.)
>
>(I have improved the exception processing in flush() -- the 
>SException.getRecordInstance is now properly set so you can diagnose 
>automatically more efficiently.)
>
>Anthony
>
>At 10:57 PM 9/08/2008, Franck Routier wrote:
>
>>Hi,
>>
>>I have the case where I try to commitAndDetachDataSet(), but there is an
>>error, say a duplicate primary key.
>>
>>Until now I was catching the exception and detaching the records in the
>>catch block, so that they were not destroyed and could be returned back
>>to the UI layer for user interaction (say, possibly, choosing another
>>pk).
>>
>>Now I can't find any method to detach a dataset, other than
>>commitAndDetachDataset().
>>
>>I could getDataSet() and manually setSession(null) on it, but this
>>doesn't seem future safe (in a future version, detaching a dataset may
>>imply other actions that simply setting session to null).
>>
>>So here is my question:
>>1) does detaching a dataset on error seem legitimate ? (if not, what
>>would be the alternative ?)
>>2) should we add a method to ses.detachDataSet() ?
>>
>>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?"


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/