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

Reply via email to