Re: Shipping a build

Hello,

I have a few other commits waiting here that I would like to go in the
build.

Mainly, it allows to do:

aggQuery.sum("some arbitrary sql here")

(or groupBy, avg, max, min, count)

For example sum("case where myfield = "TRUE" then 1 when myfield="FALSE"
then 0 end")
or
sum("(exract(epoch from myEndTimestamp) - extract(epoch from
myBeginTimestamp")) / 3600") as durationindays

I also added a hasTable(alias) method to SQuery to ease building of
conditionnal quieries.

I'll commit it to let you have a look if you want.

Then I'll rename SAggregateQuery to SQuerySelect...

Regards,
Franck

Le lundi 18 mai 2009 à 14:02 +1000, [email protected] a écrit :
> 
> 
> Hello Franck,
> 
> I would like to package up the current subversion state fairly soon
> and make it the next build. There are a few tweak I would add.
> 
> Could you have a bit of a think about what needs to be cleaned up etc.
> for this to happen. Rename SQueryAggregate to something like
> SQuerySelect is one.
> 
> I'd prefer that you made changes related to your application so that
> you do not break compatibility.
> 
> Regards,
> 
> Anthony
> 
> >Hello Franck,
> >
> >I see your point about SQueryGeneric. How about SQuerySelect, because
> it lets you explicitly specify a select list? 
> >
> >I realize that you are busy but it would be good to at least do just
> the rename plus comment as soon as possible. (I won't do it because it
> will break your code.)
> >
> >I am a little concerned about getting too clever in SDriver about
> portability. Supporting this type of thing for multiple databases is
> very hard. I think that I would prefer that you just do this at the
> application layer. You just have little methods that provide the right
> query for different DBs. Could just return strings, or possibly
> SQuerySelect (given an SQuerySelect parameter). I prefer strings, it
> is simpler.
> >
> >Regards,
> >
> >Anthony
> >
> >At 04:49 PM 19/04/2009, you wrote:
> >>Hello Anthony,
> >>
> >>I've not be changing anything recently, except adding a rawInnerJoin
> >>method to SQuery, that truly adds an arbitrary table to a query (a
> table
> >>that has no explicit SFieldReference to the query).
> >>
> >>But I have also found I would need rawSelect(), so it is definitely
> a
> >>good idea :-)
> >>
> >>The point is we are also releasing a new version of our flgship
> product
> >>by the end of the month, so I'll be quite busy right until then...
> >>
> >>Just a few more comments:
> >>
> >>> I think that specifically SQueryAggregate and friends should be
> renamed into something like SQueryGeneric. That is because the thing
> that is special about it is that it returns SRecordGenerics rather
> than SRecordInstances. One use of SQueryGeneric is to do aggregates,
> but it is more general than that.
> >>
> >>Yes, but then, when SRecordInstance will extend SRecordGeneric,
> SQuery
> >>will also return SRecordGeneric... So, are we going to have an
> abstract
> >>SQueryGeneric, with SQuery and SAggregateQuery extending it, or do
> you
> >>think both should be merged in the long term ? (right now I wouldn't
> say
> >>so, but I'm not sure)
> >>> 
> >>> Thus we should also add the easy 
> >>> .rawSelect(String rawSqlExpression, Object[]... parameters) 
> >>> which adds an arbitrary an arbitrary expression, plus .rawClause
> for completeness.
> >>
> >>Yes, that would be interesting...
> >>Another thing I found I'm missing is doing arbitray calculation and
> then
> >>doing an aggregate on it, but rawSelect wouldn't solve my problem
> >>altogether, as calculation might include database functions that are
> not
> >>standard.
> >>Typical example is I want to make a sum of durations for my records,
> >>grouped by whatever. Duration is defined by the difference between
> two
> >>timestamps... and this is something that in not standard in sql. So
> >>having portable code is not easy.
> >>
> >>eg. select sum( extract(epoch from endts) - extract(epoch from
> begints))
> >>will work for postgresql, but not for oracle etc.
> >>
> >>So another idea I had was to be able to augment SDriver (and
> >>SQueryGeneric) with specific functions (like duration(ts1, ts1))
> that
> >>could be used in queries to allow to generate sql that will work in
> each
> >>database... I didn't do anything for now, as I'm not sure about the
> >>right way to do this (just add the functions I need, or think about
> a
> >>more clever pluggable functions system, ...)
> >>
> >>> 
> >>> The simple unification of SRecordInstance with SRecordGeneric
> would complete the process, but that can be done later. I might make
> time do it myself because it will not affect your code. (It is easy,
> just have SRecordInstance implement map, with 
> >>> 
> >>Fine.
> >>As I said, I won't have much time for the next two or hree weeks,
> but it
> >>should be better after that.
> >>
> >>Best regards,
> >>Franck
> >
> >Dr Anthony Berglas, <mailto:anthony%40berglas.org>[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.
> >
> >
> 
> 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/