Here is a solution that might work:
Establish a JDBC connection to your customer database and set the
connection in the repository.xml of OJB.
Map the tables in the customer database to your Java objects using
repository_user.xml of OJB
Run an OJB query loading your Java objects.
Done
Christian Plate <[EMAIL PROTECTED]>
10/16/2003 09:48 AM
Please respond to "OJB Users List"
To: 'OJB Users List' <[EMAIL PROTECTED]>
cc:
Subject: AW: AW: Is OJB the right solution?
We can't use these tools. The databases from which we have to
import data are databases of our customers. So the formats differ and
we need an easy to automatize way of importing.
Besides we don't want to import into another Database but into our
Objectmodel.
Christian
____________________________________
I don't think OJB is the way to go for you.
Why don't you use the RDBMS bulk load utility?
Giora
Christian Plate <[EMAIL PROTECTED]>
10/16/2003 09:23 AM
Please respond to "OJB Users List"
To: 'OJB Users List' <[EMAIL PROTECTED]>
cc:
Subject: AW: Is OJB the right solution?
I'll explain our situation in more detail:
We have an existing infrastructure of Components (EJBs) and an underlying
Database. Persistance of these Components is achieved 'traditionally'
(without
O/R - Mapping tools).
We want to import Data from other Datasources (Access / CSV / Oracle,...)
into
our System. This means we don't need an persistance layer. But we need an
comfortable
(configurable/generic) way of importing this Data into our existing
Objectmodel.
Basically we want to say 'import TableA.fieldA to ObjectB.fieldA'
All we need is a generic 'loading facility'.
I'm not sure if OJB is the right tool for this purpose.
Thanks for helping!
Christian Plate
-----Ursprüngliche Nachricht-----
Von: Brian McCallister [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 16. Oktober 2003 15:04
An: OJB Users List
Betreff: Re: Is OJB the right solution?
Just from the description you gave it is likely that OJB would help
solve a lot of your problems, but I am not sure without details.
By "import" do you mean use multiple datasources for the application to
materialize the same type of object, or do you mean import data from
one schema (in database one) into database two, using database two's
schema. I think you mean the first situation -- and can say with a
definite yes that OJB can work well for you. You will need to be
careful about object relationships across datasource boundaries... hmm,
fun problem.
-Brian
On Thursday, October 16, 2003, at 04:06 AM, Christian Plate wrote:
>
> Hi!
>
> After much reading i'm still not quite sure if OJB is the right
> solution for our problem.
>
> We have an existing Objectmodel and underlying Database. Now we
> want to import data from other Datasources. These Datasources have
> different Structures. So we thought it would be a good idea to find a
> generic solution. The specification of a mapping through XML is
> excactly what we need.
>
> My Question is if OJB is the right solution for this
> 'Import-Scenario'. Should i look for something different?
>
> Thanks in advance!
>
> Christian Plate
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
________________________________________________________________________
The information in this e-mail, and any attachment therein, is
confidential
and for use by the addressee only. If you are not the intended recipient,
please return the e-mail to the sender and delete it from your computer.
Although The Bank of New York attempts to sweep e-mail and attachments for
viruses, it does not guarantee that either are virus-free and accepts no
liability for any damage sustained as a result of viruses.
________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for
use by the addressee only. If you are not the intended recipient, please return the
e-mail to the sender and delete it from your computer. Although The Bank of New York
attempts to sweep e-mail and attachments for viruses, it does not guarantee that
either are virus-free and accepts no liability for any damage sustained as a result of
viruses.
