> From: Will Glass-Husain [mailto:[EMAIL PROTECTED]] > > (3) One significant lack in Torque is a "Cursor" functionality, as > described > in "The Design of a Robust Persistence Layer for Relational Databases" > http://www.ambysoft.com/persistenceLayer.html. I did a set of pages that > displayed 20 records from a database at a time. I had to do a select from > the database each time and choose a subset of the Vector-- probably not > the > most efficient technique. A cursor functionality would have let me do one > pull from the database and use that for the display of multiple subsets.
I'd like to see a method on the Peer like this: ClosableIterator doSelectBulk(Criteria crit) where ClosableIterator extends java.util.Iterator and adds a close() method. The ClosableIterator could be backed by the ResultSet directly. > (4) Another limitation was "Criteria". Worked really well for simple > queries, but was difficult to use for more complex queries. (e.g. queries > with aggregate functions, subqueries, and complex WHERE logic). No good > answer here. There's clearly some tradeoffs between ease-of-use and power. I would like to eventually see Criteria replaced with something that looks and works a lot like RogueWave's DBTools.h++: http://www.roguewave.fr/support/docs/dbtug/4-5.cfm#451 I used this years ago in my C++ days and it was pretty cool. It provided a database-independent abstraction above SQL that accommodates outer joins, subqueries, self-joins, and just about every other SQL construct. It is based on interfaces and has pluggable implementation modules to provide mappings for each RDBMS flavor. An implementation of this would probably be most appropriate as Village 2.0, since it is useful for all manner of SQL queries, not just O/R mapping. I'm interested in working on this, but probably wouldn't be able to start for another couple months or so. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
