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 data into the object
instance. BUT you wouldn't always need to USE that data, so it'd really
be sort of a waste. Perhaps those columns are only populated (and thus
the more complex query with group by executed) if you use them in the
orderBy clause? Otherwise they would raise an error if accessed? But
this also seems not ideal...
The problem is that the extra columns are really just a part of doing a
special kind of select on the model, which is why I wanted to somehow
explicitly associate them with the select instead of the model in
general. I don't think it's THAT complicated to use the groupBy/orderBy
syntax. Semantically, it's pretty obvious and straightforward, and it
only does the grouping and selecting when you need it to. I think that's
the advantage of putting it on the select.
However, the question still remains how to get the extra values back
with the model instances. I didn't think of the caching issue. If you're
doing multiple groupBy selects that involve the same object, then
caching will probably unify the two and you could have potential
collisions on the extraColumns dict... Hrm
The only other thing I can think of is handling with the iterator like this:
results = Item.select(extraColumns={'count':func.COUNT(Item.q.id)},
groupBy=something, orderBy=somethingElse)
for obj, extraColumns in results:
print obj.id, obj.name, extraColumns['count']
Result:
1 Sam 15
2 Brad 16
etc...
Would that make sense? I kinda like it...
- Sean
Luke Opperman wrote:
> Quoting Rick Flosi <[EMAIL PROTECTED]>:
>
>> I think it might not exist b/c it isn't very SQLObjecty.
>> You'd be returning an object with a new field in it, SUM(), which isn't
>> part of the SQLObject and probably a subset of the SQLObject fields as
>> well. This isn't very OO which is what I think SQLObject was designed for.
>
> I think there are two possible scopes for this that could make me comfortable
> with it in the context of SQLObject's design. (There may be other acceptable
> designs that I'm not thinking of, of course, these are just my thoughts. :) )
>
> 1. Adding elements to the column specification of a .select, for use in the
> query but not accessible in the returned objects. This seems like a relatively
> small-scale change, and at least allows these order-by-sum queries to be
> executed. Sean McBride's proposed .select syntax sounds good, but I'm not a
> fan of the 'extra' dictionary access on instances: due to instance caching,
> these extra fields would not necessarily be limited to the instances returned
> from the SelectResult, for one.
>
> 2. Create column-like objects that encapsulate derived values into a
> declarative form. These could then be used as .q variables in .select.
> Pseudo-example:
>
> class Salesperson(SQLObject):
> name = StringCol()
> sales = MultipleJoin('Sale')
> totalAmount = DerivedJoinSum('sales', 'amount')
>
>
> class Sale(SQLObject):
> salesperson = ForeignKey('Salesperson')
> amount = DecimalCol()
>
> Salesperson.select(orderBy=Salesperson.q.totalAmount)
>
> These columns would have no createSQL, would normally be retrieved separately
> from the intial column query, and would require some (serious?) modification
> to SelectResults/SQLBuilder to a) put the joined table in tables and b) alter
> the column spec based on their explicit inclusion in the Select and c)
> potentially make other injections to the select such as the implicit groupBy
> in this example.
>
> I'd be a big fan of #2, as I tend to use derived _get_ accessors heavily and
> there are some common patterns that I'd prefer to a) be declarative and b) to
> use in queries as in this example. I can provide further examples after the
> weekend, and if people are interested I would be willing to tackle initial
> implementation next week.
>
> - Luke
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
