Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
In-Reply-To: <63057762-C3E8-11D8-83DA-000A95782782@forthillcompany.com>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Subject: Re: [OT] looking for project interest
MIME-Version: 1.0
Message-ID: 
 <OFC0469FA1.5FF27412-ON86256EBB.005839E1-86256EBB.00597391@email.zurich.com>
From: Robert McIntosh <robert.mcintosh@zurichna.com>
Date: Tue, 22 Jun 2004 11:17:04 -0500
Content-Type: text/plain; charset="US-ASCII"

Brian McCallister <mccallister@forthillcompany.com> 
06/21/2004 08:06 PM
Please respond to
"OJB Developers List" <ojb-dev@db.apache.org>


To
"OJB Developers List" <ojb-dev@db.apache.org>
cc

Subject
Re: [OT] looking for project interest


Time to chime in again...

I am not sure where I see this is different from JDO. It supports 
multiple backends, uses named instead of ad-hoc queries (where query is 
expressed in metadata with optional variables in the context rather 
than generated by interpreter), and the results are objects.

One thing to remember is that JDO, or ODMG or EJB for that matter, is a 
spec for object persistence. Chameleon is a general persistence engine 
that can support object persistence, but it is not tied to that use case. 
Oh, it will also support adhoc queries, but that isn't in there yet, with 
the exception of adhoc straight SQL queries where the results are not 
objects. Which also brings up that the results _can_ be objects, but it 
could be a series of SAX events, a DOM tree, a List of Maps (analogous to 
a ResultSet), etc.

You make a point that it isn't an O/R mapper, but a layer above other 
persistence systems. I guess I just don't get a major shift in what it 
provides.


As an O/[backend] mapper it may be great (this is an immature field, 
more projects == good) -- particularly as it looks to be designed 
specifically around plugging in various backends, which is good. Even 
better it seems to take a stab at supporting transactions across 
non-transactional sources (a pet interest of mine ;-).

Pretty close. It can be a layer above an O/R mapper and thus play the role 
of a meta-persistence engine, which isn't something I have really 
preached(?) before. It can also be an O/R mapper, with a lot more 
flexibility in the 'mapping' process. A quick example would be retrieving 
an object from a view but also allow updating of the underlying tables 
that view is based on. As for transactions, that is a touchy subject, but 
initially it will allow cross datasource persistence using JTA. I honestly 
haven't thought about non-transactional sources, but that would be an area 
that would be really cool to work on. As for the cross datasource, the 
current safest route would be a container managed transaction (or other 
JTA impl.) from which JDBC connections, JCA connection, JMS connections 
(yep I have a use for using JMS as a datasource as well) can all be 
controlled.


But... what does Chameleon provide which JDO doesn't?


1. Non object persistence.
1a. retrieve as XML. potentially update from XML
1b. tabular retrievals, much like a ResultSet without the process of 
setting up the connection. e.g. from something as simple as 'select 
count(customer_id) from customers' to any arbitrarily complex query (much 
like the report queries from what I understand)
2. cross datasource persistence (ok, I suppose a given impl of JDO could 
do this. Maybe Chameleon could even put a front end JDO API on)
3. Native query language support
4. object persistence that isn't reachable through the object layer.
5. 


-Brian

On Jun 21, 2004, at 8:31 PM, Antonio Gallardo wrote:

> Hi Robert:
>
> I read all the mails related to this post. I think it is interesting
> because new ideas are always welcomed. It is great to share ideas and 
> to
> know new approachs. I will try to participate in this interesting
> discussion:
>
> 1-In OJB, we can access write SQL statements using JDBC directly. 
> Another
> option is using QueryBySQL or ReportQueries.
>
> 2-In the case of the FastLine Reader, I think it can be incorpored in 
> OJB.
> It can be an internal enhancement that the user will no see at all. 
> This
> can be done as part of improvements efforts of the OJB community.
>
> 3-I noted that JDO os not being mentioned and I think it is important 
> too.
> The JDO support in OJB allow transparent persistence for persistence
> stores as RDBMS and filesystems in a similar manner as JBDC.
>
> 4-Also the reachability problem is solved in OJB or JDO.
>
>
> Best Regards,
>
> Antonio Gallardo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>


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


******************* 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