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 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...
I had pictured the opposite, derived columns would not be included in the column spec unless explicitly used in a .select. Today i would write this derived column as: def _get_totalAmount(self): return self.sales.sum(self.sales.otherClass.q.amount) and the version when not retrieved through an explicit select would still be this. Actually, even the select version would need to do this unless we introduce a synchronization/clear mechanism for cacheValues on joins. Hmm. More later, i'm about to lose coverage up in the northwoods. :) ------------------------------------------------------------------------- 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
