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 Sun, 20 Jun 2004 16:50:47 GMT
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 
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.


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

View raw message