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
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
