In short, Torque is more of a top down approach where you start with a definition then generate the database and object model. OJB seems a little more transparent, but follows the OO API paradigm by implementing ODMG and JDO specs. Chameleon could, in theory, ride on top of OJB, sending it OQL queries and matching the results of that to the results of another query executed via SQL, entity beans, etc. If desired an ODMG or JDO api could be put on top of it as well.
The link http://www.bull-enterprises.com/aom/persistence/index.html provides more details, but in a nutshell it does not try to impose an O/R view and API on the persistence engine. In other words, the retrieval of data may very well be an object graph, or it may be an XML document (or fire SAX events), or a 'simple' query to retrieve arbitrary data. For example, if you want to get a row count on a million+ row table, the SQL would be: "select count(*) as item_count from table feature_requests". This query could be executed that would return a single java.util.Map that is analogous to a ResultSet with just the one result item. Sometimes simple questions require simple queries! Also along the non-imposing route is that it does not force the developer into querying in an OO way, or in a readability way. Some queries just can't be executed by reachability through the graph. Not a code or database generator. While these could be added on as supportive tools, they are not the focus. Other things on the plate would include on-demand iteration. Say you want to process those million rows, but only one at a time, so the query would execute and under the covers an object instance for that row is only created as that row is iterated over. This would work in a similar way to the ResultSetDynaClass in the BeanUtils library. I mentioned XML and I have a use case for retrieving XML for a web service and for display only work, which will be transformed on the client. It seems ridiculous to generate an object graph then turn around and convert it to XML, so the persistence engine will allow going straight to XML. Most O/R tools shield the user from the actual query by using a query api, oql, etc. This type of functionality will be added later, but it is not a requirement. Some queries are just too complex to deduce from an object graph and require the native language (SQL in most cases). Ever had to do a CASE statement in sql? Unfortunately I have due to, umm, not so well designed databases. Other items of interest: - makes no assumptions about the underlying database type or schema, nor does it constrain the schema -- composite keys can be used, mapping across tables, etc. -- not constrained to a RDBMS - full sql or other native query language. If you are going against Xindice, use xquery, against MySQL, use SQL. It could even front entity beans and execute EJB-QL. This also means that you can use stored procedures and views (and update the underlying data for the view). On the plate is also fronting a web service for data retrieval. Perhaps using JAXB, Betwixt, Axis or other means to convert the web service data to objects, if objects are desired. - not constrained to a single datastore for a given object graph. -- for example, Hibernate will allow multiple databases, but you cannot have a parent child relationship where the children come from database 'A' and the parent comes from database 'B'. To be fair, OJB does mention use of multiple datasources but I honestly do not know the details of this. - support self referencing objects. Think of a Location object that has sub locations which has sub locations; semantically this would equate to Country > State/Province > County or an Org Unit which has sub units, which would equate to Division > Region > Territory. (I use the latter in production app right now). - support association classes (those that do not map to any table but are a composite of two or more objects that do) - support DynaBeans and runtime generated JavaBeans. - Pluggable expression support in the queries. Current expression support includes JSTL style via Jexl, Xpath via JXPath and future support for scripting via BSF - Multiple styles of child data retrieval: -- Lazy loading via eager (load all children for the current type of parent and populate all parents with their children) and on-demand (load only the children for the specific parent) -- Explicit children retrieval or no retrieval at all. If you know you don't need the children, then don't retrieve them. If you know you do, then retrieve them. Most 'lazy' implementations don't allow this explicit yes/no ability; if you know you may not in some queries, you either have to live with retrieving them, or mark them as lazy and suffer the overhead when you do need them. - Client-Server architecture where the client can execute queries than span multiple 'servers'. By default it will use a local VM 'server', but it could go out across RMI to a session bean based server and across HTTP to a web service based server, then collate the results of those two calls into a single object graph. The RMI and web service pieces are not there yet, I have run into a use case for the webservice where the client had a Swing app that needed to connect over a regular dial up to the backend application. As for interest, I have only floated the idea on the db general list, which as mentioned lead me to this list. I am certainly looking for others to join in and I wouldn't mind soliciting interest from other lists as well. - Robert McIntosh "Noel J. Bergman" <[EMAIL PROTECTED]> 06/09/2004 09:56 PM Please respond to [EMAIL PROTECTED] To <[EMAIL PROTECTED]> cc Subject RE: proposal > I am sending this proposal to the incubator list to see if there is > any interest for a new persistence project. > it is not just an O/R mapper, but a generic persistence engine that > can be used as an O/R mapping tool. How does this compare with Torque (http://db.apache.org/torque/) and OJB (http://db.apache.org/ojb/)? Have others expressed interest in collaborating on this with you? --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ******************* PLEASE NOTE ******************* This message, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorized recipients. If this message has reached you in error, please notify the sender immediately and promptly destroy it without review. Dissemination, distribution or copying of this communication is strictly prohibited. Thank you for your help. ********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
