On Fri, Aug 04, 2006 at 06:56:26PM +0200, Pau Aliagas wrote:
I think I put everything in bugzilla.
Do you mean SF tracker?
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
I just don't really agree that this isn't very OOpy. Obviously it
wouldn't be good to just mix the extra columns right into your existing
SQLObject instances so they're different from your definition. However,
either the SQLObject class or the SelectResults class could define some
dict-like
This sounds like a good idea.
What do you see the syntax being for creating a query with SUM()?
Will you have to define GroupBy() or will it default reasonably?
How can you do a SUM() of a field and Group it by something and return the
full object?
SELECT id, number, SUM(number) FROM table
Well, the SQLObject syntax would probably look something like this:
Item.select(Item.q.id==table.collection_item.item_id,
extraColumns = [func.COUNT(Item.q.id)],
groupBy = Item.q.id,
orderBy = [DESC(func.COUNT(Item.q.id)),Item.q.name])
The resulting SQL would then look
Quoting Sean McBride [EMAIL PROTECTED]:
Number 2 sounds decent to me too, but I can see a potential problem: A
class that had a DerivedJoinSum on it (or another one of the derived
accumulators) would ALWAYS have to do the more complicated select
statement behind the scenes in order to get the