db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert McIntosh <robert.mcint...@zurichna.com>
Subject Re: [OT] looking for project interest
Date Mon, 21 Jun 2004 13:56:07 GMT
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).

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. 

 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 
APIs. 

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.

Thanks for your time!
Robert




Thomas Dudziak <tomdz@first.fhg.de> 
06/20/2004 11:50 AM

To
OJB Developers List <ojb-dev@db.apache.org>, robert.mcintosh@zurichna.com
cc

Subject
Re: [OT] looking for project interest






Robert McIntosh wrote:

> The project is called Chameleon and it is a general persistence engine. 
It 
> can do O/R mapping, but that is only part of its capabilities. More 
> details can be found at:
> 
> http://www.bull-enterprises.com/aom/persistence/index.html
> 
> which has some rational, why and how it is different than the typical 
O/R 
> tool, some samples, etc. The docs there are a work in progress, so they 
> may not be complete in some areas.
> The current state of the project is that it is being used in one 
> production application, and has gone a bit of a refactor after that app 
> went in to production. The basics are in place with basic O/R 
> capabilities. It still needs the XML, remote servers, web services, and 
> bunch of other stuff done (there is a roadmap on the site listed).
> 
> As stated on the site, the goal is not to become another O/R tool, but 
to 
> expand persistence capabilities beyond persisting business objects to 
> relational databases. 
> 
> There are currently two other developers who have expressed interest in 
> contibuting once it is accepted (assuming it gets accepted that is :-)

 From what I see on the website, Chameleon plans to provide basic O/R 
capabilities quite similar to what other O/R tools like OJB, Torque and 
all the others do plus two additional things:

* sophisticated query support beyond that of normal QL's (though the 
website is not really informative as to what this actually means)

* transparent multi-database support, e.g. the application programmer 
does not really have to care where the data actually is (aside from the 
configuration of the O/R)

While I don't see yet what difference is between the planned query 
support in Chameleon and existing technologies, the latter could be 
interesting.
Now aside from these advanced features, I wonder why you want to create 
yet another O/R tool rather than leveraging from existing projects (like 
OJB) and build on-top of them. I understand that there is a certain 
heritage, but wouldn't it be better to re-use an existing O/R framework 
and extent it? This would free you from having to deal with the basics 
while at the same time gain you quite a few developers for your project.
And I can assure you that the OJB developer team would be quite happy to 
support you in such an undertaking.

Tom


 


******************* 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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message