Re: Re: Aggregations etc.

Hello Franck,

So, you are worse than me, coding on Easter Sunday...

Looks good to me. 

There is still an awkward overlap between SQuery, SQueryAggregate and rawQuery.

I think that you should have rawAggregator(SField fld, String rawExpression) for add hoc groups based on special functions.  The fld could be used to check the consistency of the queries, maybe later.

Also just 
  SAggregate.rawSelect(String rawExpression)
Ie. no aggregation at all.  So one could retrieve "SALARY+1".  (More useful examples would obviously involve the database, eg. text retrieval or geospatial functions.)   

(And should also have SAggregate.rawSelect(String rawExpression, Object[]... parameters). )

Also rawClause(String) which just adds additional clauses like HAVING.  (Oracle has ROLLUP clauses etc.)

So maybe SQueryAggregate should be renamed SQuerySpecial or similar.  The thing that is special about it is the arbitrary, and explicit select list, rather than the aggregations which is just one usage.  That makes sense to me.

The tableAlias parameter should really be optional, just like it is for the SQuery methods.

A common case is to say SELECT COUNT(1) FROM...  This avoids null issues, and the overhead of testing for them.  You do not currently support that.  (Maybe rawAggregator.)

SAggregateField.rawGroupBy is not tested.

(Could uncopy the conversion code by having SRecordInstance extend SRecordGeneric.  Then create
  SRecordGeneric.getObject(fieldName){return get(fieldName)}
SRecordInstance would override getObject etc.  
But probably not worthwhile unless we also move SRecordInstance to a Map implementation, a major shift requiring thought.

(Incidentally, LinkedHashMap implements Map, so no need to have Map as an interface on SRecordGeneric.)
)

Regards,

Anthony

At 10:44 PM 12/04/2009, you wrote:


>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
>
>

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/