Re: Comparing Records

Hello,

as I said in my other mail, I agree with you. I removed Comparable from
SRecordInstance.

I added a warning in SRecordComparator API to say it is not strictly
consistent with equals, but really, this doesn't really matter.

I removed nullKeysIndex.


Franck


Le mardi 24 mars 2009 à 14:25 +1000, [email protected] a écrit :
> Hello Franck,
> 
> I really do not like making SRecordInstance Comparable. 
> 
> What we really want later is to be able to apply SQueries to
> disconnected SDataSets, complete with ascending/descending clauses. So
> that means that the sort order is a property of the query, and not of
> the record. This will require using the java.util.Comparator interface
> rather than the Comparible one, and I would not like to have to
> support both.
> 
> I do not see how useful Comparible is anyway. Particularly if people
> insist on using meaningless surrogate primary keys. If records are
> queried into the SDataSet in a reasonable order then they will be
> retrieved in the same order. Eg. sorted by Name. This would seem to be
> more useful and is default behavior.
> 
> I understand comparable vs equals, but I do not like nullKeysIndex at
> all. Comparitor largely avoids this problem because we only need the
> specific case of a sorted list to work.
> 
> Do you really have a good use case? If not then I would like to remove
> this feature. Not adding features is a key to keeping SimpleORM
> simple.
> 
> (Or could you use the Comparitor interface and thus not clutter up
> SRecordInstance? Then you do not need nullKeysIndex.)
> 
> (Perhaps keep the field comparison code for use with SQuery sorting
> later. But I am wondering if the null testing could be abstracted into
> a field in SFieldInstance.)
> 
> I am rather desperate to keep SimpleORM crisp and clean because that
> is its main advantage. Any developer should be able to understand any
> part of SimpleOrm very easily.
> 
> Regards,
> 
> Anthony
> 
> At 12:51 AM 24/03/2009, you wrote:
> >COMPARE/NULL KEYS INDEX
> >> =====================
> >> 
> >> I do not understand why you needed these. 
> >
> >In fact, to make SRecordInstance Comparable, we need a way to impose
> an
> >order on them. Ordering records based on their primary key(s) value
> >seemed the way to go. This order should be consistant with equals (it
> is
> >not mandatory but strongly advised).
> >SRecordInstace.equals() has a special behaviour to handle null
> primary
> >keys (for generated keys while not in session) : two instances with
> null
> >keys are NOT equal. So they must have a defined order, and we cannot
> >just rely on comparing two nulls for that
> >
> >(See also the following excerpt from Comparable javadoc : Note that
> null
> >is not an instance of any class, and e.compareTo(null) should throw a
> >NullPointerException even though e.equals(null) returns false.)
> >
> >So we must handle the case...
> >
> >> 
> >> I am concerned about inconsistent behaviors with null keys index as
> >> the keys are assigned. It does not feel right at all.
> >
> >Oooops. This is a bug ! I added a method to reset this field when a
> key
> >is generated (on flush). I think this should do the trick.
> >> 
> >> Do you really need to sort on primary keys? And if you do, what is
> >> wrong with just having the null keys sorted to the beginning in
> update
> >> order?
> >
> >It could be a possibility, but I choosed to put nulls last for two
> >reasons :
> >
> >1. some sql put nulls last be default (incl. Postgresql, DB2,
> Oracle).
> >2. nulls key will probably be newly added records with sequences (or
> >select max...), so at the end they will probably end up having a
> greater
> >primary key than the one that already have a key.
> >
> >> (The Java sorts should be stable, ie. preserve the order of records
> >> with keys of equal value.)
> >
> >Yes, but keys with null value are not equal... They are null, so not
> >equal to anything.
> >
> >> 
> 
> 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/