Werner, its no problem if table in Oracle and Sybase have the same name, but classnames have to be unique. In your example you would need e.g. AccountNaturesOracle and AccountNaturesSybase classes. An other solution would be that objects mapping to 2 databases can not be used with automatic mapping resolution. For this situations it should be possible to get a Database object for a specific database as it is today.
There are some more problems but also advantages:
1. Within such a transaction objects in 2 databases can be modified and therefor should only be commited if both succeed, or rolled back if one fails.
2. OQL queries can involve objects in more than one database.
3. With the new datasource concept of Bruce the transaction and also OQL queries can involve not only 2 relational databases but also LDAP directories. Maybe also XML documents can take part.
4. The user of castor do not have to take care where the object is stored because its only defined in the mapping. It would be very easy to move an object from one storage to another by only changing the storage mapping.
It's clear to me that this would be very difficult but according to the advantages it may be a target for the future.
Regards Ralf
----- Original Message ----- From: "Werner Guttmann" <[EMAIL PROTECTED]>
To: "Castor" <[EMAIL PROTECTED]>
Sent: Wednesday, September 15, 2004 10:58 PM
Subject: Re: [castor-dev] New datasource interface (was: Working with Castor's internal JDBC connection)
Ralf, so what if there's an overlap of types in the two databases ? Let's imagine that you are to store AccountNatures in e.g. Oracle and Sybase, for the
sake of this thread ? I am not sure whether what you are asking for is actually achievable.
Werner
On Wed, 15 Sep 2004 12:07:54 +0200, Ralf Joachim wrote:
Hallo Bruce,
thanks for your answer and it is good to know that castor supports connections to more than 1 database.
With the previous mail I also wanted to present an idea for an improvement.
I'll give it another try.
Let us assume we have 2 databases A and B, where AObject's are stored in A
and BObject's in B. With many database support of castor the code to load an
AObject and a BObject would look like:
JDO ajdo = new JDO(); ajdo.setConfiguration( "database.xml" ); ajdo.setDatabaseName( "A" ); Database adb = ajdo.getDatabase(); adb.begin(); AObject a = (AObject)adb.load(AObject.class, aid); adb.commit(); adb.close();
JDO bjdo = new JDO(); bjdo.setConfiguration( "database.xml" ); bjdo.setDatabaseName( "B" ); Database bdb = bjdo.getDatabase(); bdb.begin(); BObject b = (BObject)bdb.load(BObject.class, bid); bdb.commit(); bdb.close();
Wouldn't it be nice if castor can deside from database.xml and the mapping included in it from which real database to load the object. With this feature the code to load above 2 objects would look something like:
JDO jdo = new JDO();
// database.xml defines connections to databases A and B jdo.setConfiguration( "database.xml" );
// get an abstract database object without connection to a real database Database db = jdo.getDatabase();
// Start transaction db.begin();
// create connection to database A includes it in the transaction and loads
AObject
AObject a = (AObject)db.load(AObject.class, aid);
// creates connection to database B includes it in the transaction and loads
BObject
BObject b = (BObject)db.load(BObject.class, bid);
// commit to both databases db.commit(); db.close();
Hope this example makes the idea more clear to you.
Regards Ralf
----- Original Message ----- From: "Bruce Snyder" <[EMAIL PROTECTED]>
To: "Castor" <[EMAIL PROTECTED]>
Sent: Wednesday, September 15, 2004 10:15 AM
Subject: Re: [castor-dev] New datasource interface (was: Working with
Castor's internal JDBC connection)
Ralf Joachim wrote:
I thougth it may be better to start a new tread for discussion on new
Datasource interface. I appended the Datasource part of the original mail
below.
I was going to do the same thing ;-).
As I do not know how you think the new interface should look like and if
there are that much differences to the old Database interface my question
may be stupid, but isn't it possible that the RelationalDataSourceImpl
also implements the Database interface. If this would be possible we can
get both interfaces work in parallel and therefor get a migration to the
new interface step by step?
I was speaking with a friend about this today. On my ride home today I was
thinking that maybe we could shoehorn it in to the TRUNK somehow.
Until now I only used castor to connect to a single database. For the
future I also need to connect to more then one database and I don't know
if this is posible with castor at the moment. If it is possible with the
current castor implementation I will need a connection to Database A to
e.g. load a AJDO and a connection to Database B to load BJDO. Wouldn't it
be interesting to get a single Database object that desides according to
the configuration and mapping to load AJDO from Database A and BJDO from
Database B?
Up until April of this year, Castor could connect to as many databases as
you want by using many <database> elements in the database/jdo-conf
descriptor. But this functionality was broken and has a patch pending
here:
http://bugzilla.exolab.org/show_bug.cgi?id=1594
I've been thinking about creating a new interface model like so:
+-------------+ | DataSource | +-------------+ # | +------------+------------+ | | +------------------------+ +----------------+ | RelationalDataSource | | LdapDataSource | +------------------------+ +----------------+ . . /_\ /_\ | | | | +------------------------------+ +------------------------+ | RelationalDataSourceImpl | | LdapDataSourceImpl | +------------------------------+ +------------------------+
For a description of this ASCII UML, please see the following doc:
http://c2.com/cgi/wiki?UmlAsciiArt
In the diagram above, the DataSource interface would replace the current Database interface. The second layer allows any additional DataSource type to be added (JCA connectors to AS/400, etc.). The third layer is a replacemet for the current DatabaseImpl.
Bear in mind that changes this significant would not go into the TRUNK. We'd need to create a 1_0 or 2_0 branch for it. With the big changes we're thinking about, we need to leave the TRUNK alone and only do minor changes and bugs fixes.
Bruce -- perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://incubator.apache.org/projects/geronimo.html
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
