Re: Aggregations etc.

Hello Anthony,

> === RETURN TYPE ===
> 
> I really wonder about SFieldAggregate.  It is quite different from other SFields as there are instances per row.  It is also somewhat less efficient -- many more object instances at the field level.  Why not use
> 
>   result.getLong("numberOfEmps")
> 
> which is more consistent with normal record/field access.
> 
> We just create a new class SRecordAdHoc extends Map.   Later SRecordInstance could extend SRecordAdHoc, and thus provide the Map interface I was talking about later.  This should also uncopy the code between SRecordInstance.getDouble and SFieldAggregate.getDouble (say) -- please never copy code.
> 

I've done this. SRecordAdHoc feels a bit strange to me, as
SRecordInstance is not really an adhoc object... but I don't have any
really better alternative. I guess you wouldn't like STupleInstance,
would you ? :-) I tried SReocrdGeneric, but I'm all open for
alternatives (and I could go for SRecordAdHoc if you insist).
> 
> Once this is done, then rawQuery should also be changed to also return lists of SRecordAdHoc, which should not break compatibility because SRecordAdHoc extends Map.  The same type conversion facility would then be available to rawQuery for free.
> 
I'll try that too.

More to come.

> Please do try to commit between updates.  Ie the refactor of SQueryExecute vs the Aggregates.  Makes it hard to follow the changes otherwise.

Ok. (in fact I had not planned to refactor SQueryExecute, but had to do
it when implementing SAggregateQueryExecuute).

> 
> For important structural changes a short design doc would be good, ideally before coding.  It can be written as an extension to the white paper -- API usages are the most important.
> 
> Let us leave Batch Updates go until we sort out the other issues.  They are a bit messy because of the awful way that they are implemented by JDBC -- the updates need to be grouped together by table to be effective.  There is also alternative implementation strategy, which is simply to use an updatable cursor -- can be much faster for some situations.  For OLTP it is unclear how much is really gained.

Agreed. In fact batch updates implies a different code flow as I
understand it, but cannot be the default as some drivers don't implement
it... Let keep this one for later.

> (PS.  Emails like this one take several hours of thought to produce.  And it is still rough.)
> 
I'm utterly conscious about that and really appreciate your input !

Regards,
Franck




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

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/