db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: [OT] looking for project interest
Date Mon, 21 Jun 2004 14:46:18 GMT
Robert McIntosh wrote:

>Thanks for the response Tom. One major thing was missed in your assesment, 
>and I admint it is the hardest to get across. That is that Chameleon is 
>not specifically an O/R tool but a general persistence tool, although it 
>can be used as an O/R tool, it is not tied to that role. Because of this, 
>it can do retrievals where the results are not an object graph.  The 
>simplist analogy would be like how the JSTL SQL tags work, they execute 
>and return back a result of Maps, not JavaBeans, and it also allows the 
>future support of retrieving data straight into XML, bypassing the object 
>layer. This also means that data can be updated without having to go 
>through an object first, which is useful when the data isn't in the object 
>model, such as audit information (last updated user and time for example).
Mhm, OJB can do this already, I guess, using DynaBeans and 
ReportQueries, though perhaps not as comfortably.

>To top it off, all of these scenarios can be used in the same application 
>or even in a single query, so one query could retrieve XML, say for a data 
>feed of some sort, another could retrieve an object graph (of the same 
>data as the XML retreival) and yet another could do a 'simple' query that 
>doesn't return objects, but Maps that represent a more tabular data 
>format. I tried to cover these on the persistence index page and the 
>comparisons page.
>As for query support, it will allow full native query language support, be 
>it SQL via stored procs, straight SQL, etc., or maybe it's XQL hitting an 
>XML database as well as some form of 'automatic' mode much like OJB and 
>Torque provides where it generates the SQL from an incoming OQL or other 
>format. Also, each object in the graph can be aquired via any of these 
>means, so that object 'A' could come via SQL and object 'B' comes from an 
>XML database, or whatever the case may be. 
I don't know whether this a good way; at least it gives you the burden 
of supporting multiple query languages (and e.g. XQuery is not pretty, 
believe me). Especially since SQL is by no means a standard, so you 
don't gain anything here. Imagine an Oracle user who is used to his 
PL/SQL, coding SQL queries in your system. You don't want to support all 
SQL derivates, do you ? There are even multiple ANSI (or was it ISO ?) 
SQL standards.

>While I hate to admit it sometimes, there are times when an object graph 
>just gets in the way of what needs to be done, and a strict O/R tool 
>leaves you hanging. The Fast Lane Reader pattern I mention on the website 
>is a good example where the tool, EJB in that case, couldn't really do 
>what needed to be done or do it effeciently, and the result is going 
>straight to JDBC. JDBC isn't hard, but it shouldn't be necessary to switch 
Agreed. But that's where Report Queries come into play in the O/R tools 
that I know.  BTW, where is that Fast Lane Reader pattern that you 
mentioned, I couldn't find it ?

>You mention building some of these features on top of an existing O/R 
>technology. In some cases this could work, but in other cases it is kind 
>of backwards, because it would mean the underlying technology is object 
>based, which isn't what is needed, say for XML. It is far easier for me to 
>build O/R features on top of a generic persistence engine than the other 
>way around.
For XML that would actually be a good way because XML is tree-based, so 
you have an object graph per definition which you can easily provide via 
DynaBeans. Same for LDAP. There are few datasources out there that do 
not model some sort of tree of graph AFAIK (even RDBMS do to some extent 
due to the ER/EER model).

I don't want to talk you into using OJB, but I must admit that I'm still 
not convinced that you're not reinventing the wheel with some parts of 
Chameleon. Do you have a comprehensive sample that shows off these 
features ? We could then try to see how one would implement the same 
with OJB. This should show the shortcomings of OJB and other existing 
O/R tools, right ?!


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message