Johan Dahlin <jdahlin <at> async.com.br> writes: > I wrote something similar a couple of weeks ago, I didn't submit it to > the mailing list because it was not in my opinion clean enough to be > submitted upstream.
Indeed, I make no specific claims that my code is ready to be released into the wild yet. :) Thanks for sharing your code too. > The idea behind it is to avoid SQL views and instead define your own > composite objects which uses columns from different tables. > SQLBuilder works so you can access ViewableSubclass.q.column which will > be translated to the real query defined in the columns dictionary. > GROUP BY is done magically behind you if a function is used. I plan > to add a white-list of aggregators so you can use non-aggregate > functions at some point (where GROUP BY makes less sense) Impressive, we're on much the same page - my patch also does the auto groupBy / joins for aggregates (with the same "any SQLCall is treated as aggregate" limitation), column query definition is the same (although mine are defined in full Col objects), and we're definitely both trying to solve the same problem. Mine is currently missing dynamic schema changes (addColumn/delColumn etc) and any way to provide a more complex base restriction than a simple clause can handle (ie, your "joins" attr). Also, it appears you're using InheritableSQLObject, I have no idea whether mine works with that. (Based on the tests I don't think this patch breaks Inheritable, I just don't know if Views over Inheritables works. But if you're interested in trying this out, I'd love to know what breaks.) > It does not implement any kind of caching yet, so a new object will > always be returned. I plan to solve this once it is a real problem to me. I'd tried approaches similar to yours in the past, the real impetus making this feasible for me now (with the sqlbuilder changes prior) is precisely that ViewSQLObject is a minor subclass over SQLObject and uses all the same Cols etc - so immediately all of SQLObject's cache/cacheValues, column type conversion, _get_X shortcuts, etc are functional. ForeignKeys, Join relationships, etc as well, just as you're used to in your SQLObject classes, including View->SO, SO->View, and View->View. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
