Re: Comparing Records

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/