Re: SDataSet.removeRecord(SRecordInstance rinst)

Hello Damien,

Yes, I think that you have found a bug.  

It will only arise in practice if you actually call removeRecord.  Normal operations such as Flush and Delete do not remove the records from the dirty list, and so will not trigger the bug.

For now please just null the entry in dirtyRecords.  Do not try to update the updateListIndex references.  That is because Flush and Delete just null the entry, and the behavior should be consistent.  

(If ever you did want to actually dirtyRecords.remove the entry then it should be done consistently everywhere.  That is a substantial job, and I think that the benefit, if any, would be minimal.)

Please also rename updateListIndex to dirtyRecordsIndex to be consistent.  (dirtyRecords used to be called updateList.)

But first please also look at the exception that you received when you found the error.  It should have been a clear, fail fast message about inconsistent data structures.  If not, we may need another test.  Also please add a failing test case before fixing the bug.

Finally, please do try commenting out "implements Serializable" from SRecordMeta and SFieldMeta.  If it does not break your application then we will remove them for good.  I was always suspicious about them, and now I am pretty sure they are plain wrong.

Thanks,

Anthony

At 08:27 PM 16/02/2009, you wrote:

>Hello,
>
>I just find a bug in the method removeRecord from the SDataSet object. 
>It seems that each SRecordInstance in the dataset have a updateListIndex 
>attribute. This attribute is used to quickly find the index in the dirty 
>record list from a dataset. When removeRecord is used, the dirty record 
>list shifts all elements from the deleted one to the end of the list, so 
>that the deleted record is removed ! All the record updateListIndex from 
>this point are no longer correct. They bind their old position in the 
>list, not the new.
>
>I don't know which way is better to avoid the bug, substract 1 from all 
>index that have been shifted or not remove the record but set the array 
>entry to null ... ? Setting to null is quicker but may be the cause of 
>futur bugs. I could trust the unit test to validate the fix. I think 
>shifting the updateListIndex is more reliable even if it add more cpu work.
>
>-- 
>HOSTIN Damien - Equipe R&D
>Tel:+33(0)4 63 05 95 40
>Société Axège
>23 rue Saint Simon
>63000 Clermont Ferrand
>www.axege.com
>
>

Dr Anthony Berglas, [email protected]       Mobile: +61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose
does not necessarily mean that is the best way to collect firewood.


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

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/