i want to configure multiple datasources in Play framework 2.1 with jpa.
one is H2, and the other is Oracle.
so i added the code like this in application.conf:
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:file:E:/myproject/setup/db/monitor"
db.default.user=sa
db.default.password=sa
db.default.jndiName=DefaultDS
jpa.default=defaultPersistenceUnit
db.oracle.driver=oracle.jdbc.driver.OracleDriver
db.oracle.url="jdbc:oracle:thin:#10.1.20.10:1521:prjct"
db.oracle.user=LOG_ANALYSE
db.oracle.password=LOG_ANALYSE
db.oracle.jndiName=OracleDS
jpa.oracle=ojdbcPersistenceUnit
i don't know how to assign for jpa.oracle and give it a meaningless name. but it does not show any errors. should i change it and how?
the main problem is: how can i tell Play which entities are managed by default datasource what others by the other, oracle?
for example, class A, B's tables are in H2 and class C, D's tables are in oracle. what should i codding for these entities to assign the datasources?
Finally, i found the way to connect to different db sources.
in play, the api of jpa has no method named getJPAConfig("").
thers is another construction of em(), em("").
so i access the dbs as:
EntityManager em0 = JPA.em("default");
EntityManager em1 = JPA.em("oracle");
that's it!
I did not used this feature (yet) but you have to useone of the annotations on your Models:
#PersistenceUnit(name="default")
#PersistenceUnit(name="oracle")
Or when you query yourself you can alsow specify it as:
EntityManager em = JPA.getJPAConfig("oracle").em();
Related
JPA: is there a way to map some entities to a schema of another database instance? e.g.,
#Entity
public class Foo {
}
#Entity
#Table(schema="schema1")
public class Bar {
}
The Bar entity is mapped to the schema1 of the same database instance. Is there a way in JPA to map it to a schema in a remote database instance? It is useful for sharing entities among multiple applications.
Can the "catalog" be used for this purpose?
What do you mean by 'remote database'?
If you use #Table(schema = "myschema", name = "bar"), Hibernate will qualify all queries with the schema name (e.g. SELECT e FROM Bar will ultimately translate to SELECT * FROM myschema.bar). If the database user you're using to connect to the DB has access to myschema.bar (whatever such a DB object is), then the query will work; if not, then the query will fail.
If you mean 'a remote DB that is a separate server', then, of course, you can only connect to the DB using one JDBC connection per persistence context. If that's your scenario, perhaps you should consult the docs of the RDBMS for ways to connect two DB instances (in Oracle, for example, you could use database links and synonyms).
Make sure that you understand the implications, though, as such a solution introduces its own class of problems (including the fact that you suddenly have implicit distributed transactions in your system).
As a side note, I'm not sure how such an approach is 'useful for sharing entities among multiple applications' or why one would even think 'sharing entities among multiple applications' is somehow useful, but I'd seriously think through the idea of integrating multiple application via shared/linked DBs. It usually introduces more problems than it solves.
If I understand well what you mean, you should use two (or more) different persistence context
I'm attempting to add Crate.IO capability to an existing Spring Data/Eclipselink/MySql web application. For this specific use case, we want to persist data to both MySql AND Crate (for evaluation purposes) in the most painless way possible. I'm using the Spring-Data-Crate project in order to be able to use Spring Data Repositories with Crate.
I've been able to setup a separate Crate specific entity manager with a filter to only utilize repos that implement CrateRepository. The problem I'm having is determining how to use the existing Spring Data/MySql entity classes with Crate. (or derive from them)
1) If I annotate an existing Spring Data #Entity class with the Spring-Data-Crate
#Table annotation, the mapping to the crate DB will fail because EclipseLink/JPA adds hidden persistence fields to entities objects that start with an underscore, which is apparently not allowed by the spring-data-crate adapter
2) I tried to use entity inheritance, with a base class that both the MySql and Crate entity can extend, with only the MySql entity having the spring data #Entity annotation. Unfortunately, this causes Spring Data to lose visibility of the base class fields unless the base class is annotated with #MappedSuperClass. But adding this annotation introduces the hidden "_"-prefixed persistence properties to the derived crate entity.
3) I could use separate entities entirely and have them implement a common interface, but I can't assign the interface as the type of the spring data crate repository.
... Not sure where to go from here
Spring Data Crate adapter project - https://github.com/KPTechnologyLab/spring-data-crate
Spring Data Crate Tutorial - https://crate.io/a/using-sprint-data-crate-with-your-java-rest-application/
i'm johannes from crate.
we didn't test the use of spring data crate in that manner so we can't state any information if this should or shouldn't work.
sorry, johannes
I'm using Oracle DB as RDBMS, and I want to access, via my JSF2 application, to two database schema.
So, I think I must use two <persistence-unit> in my persistence.xml ?
If accessing two database schemas means just that some of the entities should be in different schema, that can be easily done with Table annotation:
#Entity
#Table(schema="someotherschemathandefault")
public class EntityInOtherSchema {
...
}
If those schemas need different credentials to access (or different datasources to be used), then defining two persistence units is way to go.
My EntityManager is using a persistence unit that uses a data source provided by our Websphere configuration. The DS configuration includes an environment specific DB to use.
The EM successfully uses this schema, but I can't figure out a way to log or display the schema being used. I was thing something like em.getCurrentSchema would be available..
Any help would be great, thanks.
No API to do this (in JPA). You could do it via JDBC and use of DatabaseMetaData.
JPA is to provide an object view of the data and ease persistence of those objects, not to just present datastore specifics to the user.
I have an entity bean that will represent an expected result over multiple databases/datasources and can also be different queries executed, but same result always comming back. So the bean is re-used over different datasources that should be able to be dynamicly selected.
Is it possible with JPA to select during runtime the data source to be used to execute a query, and return the same type of entity bean?
Also, does my ejb/application need to define the datasources that will be used? Or can I always specify via jndi what datasource to use? Modifying the descriptor's and re-deploying an application everytime a new datasource is created is not an option.
Sorry if the question does not make 100% sense, rather difficult to get the idea through.
Is it possible with JPA to select during runtime the data source to be used to execute a query, and return the same type of entity bean?
You can't change the datasource of a persistence unit at runtime. However, you can configure several persistence unit and use one or another EntityManagerFactory. Maybe JPA is not the right tool for your use case.
Modifying the descriptor's and re-deploying an application everytime a new datasource is created is not an option.
And how will the application be aware of the "available datasources"?
You can change the JPA datasource at runtime, but the approach is tricky (introspection, JPA implementation specific, ...).
I've implemented my own implementation of javax.persistence.spi.PersistenceProviderwhich override the org.hibernate.ejb.HibernatePersistence and sets the datasource in both the Map and PersistenceUnitInfo of the PersistenceProvider just before creating the EntityManagerFactory. This way, my EntityManagerFactory has a datasource which has been configured at runtime. I keep my EntityManagerFactory until the application is undeployed.
You could use the same be approach and create N different EntityManagerFactory, each with its specific datasource. However keep in mind that each ÈntityManagerFactory uses a lot of memory.