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 Tue, 22 Jun 2004 16:26:03 GMT
Brian McCallister <mccallister@forthillcompany.com> 
06/21/2004 08:43 PM
Please respond to
"OJB Developers List" <ojb-dev@db.apache.org>

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

Re: [OT] looking for project interest

Ignore my previous post -- I am starting to grok Chameleon... maybe.

On Jun 21, 2004, at 12:31 PM, Robert McIntosh wrote:

> It is even feasible to front EJBs or even OJB for that matter.
> Chameleon could execute OQL down to OJB, and bind those results with 
> the
> results of a JDBC-based call, and bind those results with the results 
> of a
> web service call, all into one object graph. A bit over the top for a 
> use
> case I'll admit, but not totally unrealistic.

Very feasible, unfortunately. I once had a series of projects where we 
had to bind data extracted from (multiple) images to relational data 
;-) We didn't use OJB (if OJB existed then, I didn't know about it).

In my work, for an insurance company, there are tons of legacy and RDBMS 
systems in place and we are starting to build applications which need to 
access more than two or three databases at the same time. Some projects 
are batch in nature, where we load from one and send to another (sometimes 
using JMS) and others are customer focused where some data is stored in a 
common database, such as org structures and employee data, and the 
app-specific data is in yet another database. 

I definitely see the need for good backend glue projects (BEA's Liquid 
Data being my primary example of late).

How would Chameleon handle some bizarre binding like this?

I am not aware of Liquid, but I'll take a look at it. 

Also, how does it handle updates/inserts?

At the moment, it does inserts and updates by executing SQL that is 
provided in a config file. The substitution of parameters comes from a 
context and the parameters can be basic variables, objects which are 
interogated via expressions (see 
) or, soon to come, evaluated by a script and plugged in. This means that 
the data does not have to come from an object property or object instace. 
I have stubbed in and done some minor work on a more traditional 
transparent way of inserting and updating where the command (SQL 
initially, but it could be OQL or whatever) is generated based on the 
mapping file.

Good questions!


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

View raw message