incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert McIntosh <>
Subject RE: proposal
Date Thu, 10 Jun 2004 16:04:15 GMT
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

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 

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 

- Robert McIntosh

"Noel J. Bergman" <> 
06/09/2004 09:56 PM
Please respond to


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 ( and OJB

Have others expressed interest in collaborating on this with you?

                 --- Noel

To unsubscribe, e-mail:
For additional commands, e-mail:


******************* 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:
For additional commands, e-mail:

View raw message