In a single Mysql database installation I can create different databases with cross-database relationships. My goal is, for example, to use relationships between people on database A and adresses on database B.
It seems that EclipseLink has recently added support for such cases Composite persistence unit
Unfortunately more exhaustive examples are hard to find and above all the Composite persistence unit merges persistence.xml files from different jar. In the project I'm currently working on I don't have classes and entities divided in different jars based on the database they refer to. Frankly, watching the documentation on Eclipselink, I cannot figure out the real effort to make the code compliant with what Composite persistence unit requires.
Do you have any experience with it ?
Are there alternative ways ?
Thanks
Filippo
Are you databases different databases or just different schemas on the same database?
If the are just different schemas, then you don't need composite persistence units, just set the schema in the #Table.
For different databases you can use composite persistence units, the documentation is here,
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Composite_Persistence_Units
You don't need to have all of the persistence unit classes in the jars (although that is the easiest way to do it. You could just have all of the classes in the root jar, and list the classes in the persistence.xml, and on have the composite persistence.xml in the composite jars.
Related
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
I have just heard about that JPA specification is now available and usable for nosql databases. My question here is, is it the same as the one which we are used to use with relational databases ? because there are many differences between relational and nosql database especially when we talk about transaction which is not the same whatsoever. Did oracle release a new specification that encompasses new changes for nosql databases ?
regards
JPA is defined totally for RDBMS datastores. See Oracles specification.
There are a few of the well known JPA implementations that have extended their support for JPA to also allow some non-RDBMS datastores to be used with the same API (the original one that did this was DataNucleus JPA, but Hibernate and EclipseLink have copied this since). While you can use the same API for persistence, you have to be aware that you make some compromises since the query language in particular is not always suited to non-RDBMS datastores. There are no plans (that I know of) to have a JPA spec for non-RDBMS.
There is a JDO (Java Data Objects) persistence spec that applies to RDBMS and non-RDBMS, and the JDO API is more suited to many different types of datastores.
We have a requirement for building a database crawler. The application parses the tnsnames, connects to each database and retrieves some information like version, accounts, etc. We are trying to use JPA across the other parts of the application and to persist this data into the application's database.
So far, I only see creating an EntityManagerFactory programmatically for every database. Is there any other options?
We are using Spring, are there any benefits that Spring brings to the table in this scenario?
Thanks
JPA is clearly not the right tool for this job. JPA allows creating functional entities mapping a well-know database schema. Your tool doesn't know anything about the schemas and tables it will find. There could be 0 tables or 5000, with completely unknow names.
You need a much lower-level API to do what you want, like JDBC.
You could use JPA to store the results of your crawlings in a single schema, though.
Is there a way to split a database using JPA (eclipselink)? I would like to separate the system data from the client data.
I would like to have relationship between them and if possible being one Persisence Unit.
Not sure what you mean. But you can have two persistence units, one for a client database, and one for a system databases.
If you want to use them as a single persistence unit from your application, or want to have relationships between the two, you can use Composite Persistence Units in EclipseLink.
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Composite_Persistence_Units
If I already have a database schema complete, can the entity framework somehow generate the storage schema for me?
Or if I have the classes developed, can it generate the other xml's desribing the classes and their relationships?
Most can yes... I believe what you would be looking for is hibernate tools (tools.hibernate.com). Toplink and other frameworks should have equivalent functionality. You essentially provide login/db provider information, and it queries the catalog and generates xml and classes