The company I am working for stores their client data in a separate database schema for each client. They indicate that this cannot be changed at this time. Is there an efficient way to pull data and update data in all schemas without configuring a connection for each schema? Everything I can find when I search seems to be talking about using one or a couple of schemas, but I need to use many (100+) simultaneously.
In any given persistence context, each JPA entity class is mapped to a specific base table. Whether and how easily you can access multiple schemas via a single DB connection is a function of your DBMS, your JDBC driver, and perhaps your particular database, but even a combination that in general supports the kind of access you would need will still not allow you to map the same entity class to multiple distinct base tables in the same persistence context.
You might be able to use the same entity classes for different clients by associating a different persistence context with each client, but that will not allow you use the same DB connection for all of them. Thus, if using the same connection were possible for you at all, it would require different entity classes per client.
Have you considered creating a new DB user and creating SYNONYMS for each of the tables in the separate database schemas ?
You could then map JPA entitys to the SYNONYM names that you have created..
Using this approach you could still use the one DB connection but with SYNONYMS to the DB tables in the other schemas...
Related
I am new to spring framework recent i have made small project on microservices, where i create two microservices
department service
User service
I need to know how can i use join in them, i have create one common field in both the service i.e departmentId,
when i use getmapping in user service containing department id fetching the data from department service in respective to that departmentId.
Using intellij, mongodb as database, spring framework,java
Since mongo is a document store type database.
It depends on how the data will be used. You'll need to think how the data will be queried, what will the response may be.
In a RDBMS, it is natural to denormalize your data and split it over several tables and use joins to create the views you need.
In a document store you do exactly the opposite you'll normalize your data and try to include as much as you can to satisfy most queries in one query.
When you use spring, you might also like to use https://spring.io/projects/spring-data-mongodb
If you want to gain in-depth knowledge on mongo, they have several courses available where they can teach you for free: https://university.mongodb.com/
I have a use case where the same native query : create user identified by passwd needs to be executed across multiple databases ( mostly oracle ) depending on the input from user. Will this require a separate dao (repository) for each database or can I create 1 DAO and re-use it across?
I am configuring the different databases via java-based configuration to get the jdbc-database url etc and have marked one of them as primary. I don't want to create multiple DAOs as all will contain the same piece of code.
If the same DAO can be reused, how do I specify on which database to run the query at?
I'm designing an application that will use data from several databases. I'll use JPA to implement persistence and Spring as main application framework.
I need to handle transactions that will span among different datasources. Googlin' a bit I found that JtaTransactionManager could be useful to implement this.
But I'd also like to create relations (at application level) among entities belonging to different datasources. So that I can work as if the data-layer consists of a single database, without having to worry about the source which the entities "come from".
Will JtaTransactionManager let me do this, or I need some extra component or configuration in Spring?
I know no easy existent solution to your problem.
The JtaTransactionManager will take care of executing operations with different databases/datasources within the same transaction, but you won't have the data consistency guaranteed by any databases (like foreign keys between databases).
Besides, JPA does not support #ManyTo* relationships between different databases (like EntityFromDb1 has a OneToOne relationship tp EntityFromDb2), so the solution would be to work with the corresponding Ids. Afterwards it is your task to manage those relationships. Of course with some work from your behalf you could automatize the load of relationships, but there is much more that only that, like cascading, locking, queries joining both databases...
In my java application I have some serialized entity classes with inheritance. When saving instances of these classes i am converting them to a byte array and saving to a longblob column in my database table. Is there any advantage using hibernate to implement this program. Because as far I understand hibernate is used to map entities with database tables in a proper way. But here I don't have a relational model to map attributes of entities. I am saving them as objects. Am I missing something. Please clarify me. Thanks in advance.
If you don't have a relational data model to save those objects and you can't change your schema, then you can use your current approach.
If you use PostgreSQL you might be interested in JSON storage as well. That way you can store your hierarchies using JSON objects and you can even run native SQL queries against them (although not inheritance-aware, but you can cope with that if you use some _class column to differ between object types).
The cleanest approach is to have the relation model in sync with your business domain model. That way you can benefit from:
optimistic locking (preventing lost updates phenomena)
caching (2nd level cache and query cache)
query-able hierarchies
an external DBA hierarchies could run an update on your hierarchies using mere SQL
auditing
There's an enterprise application using Java + Hibernate + PostgreSQL. Hibernate is configured via annotations in the Java source code. So far the database schema is fixed, but I faced the problem that it needs to be dynamic:I can receive data from different locations and I have to store these in different tables. This means that I have to create tables run-time.
Fortunately, it seems that all of these data coming from the different institutes can have the same schema. But I still don't know how to do that using Hibernate. There are two main problems:
How to tell to Hibernate that many different tables have the same structure? For example the "Patient" class can be mapped to not just the "patient" table, but the "patient_mayo_clinic" table, "patient_northwestern" table, etc. I can feel that this causes ambiguity: how Hibernate knows which table to access when I do operations on the Patient class? It can be any (but only one) of the former listed tables.
How can I dynamically create tables with Hibernate and bind a class to them?
Response to suggestions:
Thanks for all of the suggestions. So far all of the answers discouraged the dynamic creation of tables. I'll mark Axel's answer, since it achieves certain goals, and it is a supported solution. More specifically it's called multi-tenancy. Sometimes it's important to know some important phrases which describes our problem (or part of our problem).
Here are some links about multi-tenancy:
Multi-tenancy in Hibernate
Hibernate Chapter 16. Multi-tenancy
Multi-tenancy Design
EclipseLink JPA multi-tenancy
In real world scenario multi-tenancy also involves the area of isolating the sets of data from each other (also in terms of access and authorization by different credentials) once they are shoved into one table.
You can't do this with Hibernate.
Why not extend your patient table with an institute column?
This way you'll be able to differentiate, without running into mapping issues.
I am afraid you can't do this easily in Hibernate. You would have to generate the Java source, compile it, add it to your classpath and load it dynamically with java.reflection package. If that works, which I doubt it, it will be an ugly solution (IMHO).
Have you consider using a schema less database i.e: NoSQL databases or RDF
databases. They are much more flexible in terms of what you can store in them , basically things are not tight up against a relational schema.
In most environments it is not a good idea to create tables dynamically simply because dbas will not give you the rights to create tables in production.
Axel's answer may be right for you. Also look into Inheritance Mapping for Hibernate.
I agree that its not advisable to create tables dynamically nevertheless it's doable.
Personally i would do as Axel Fontaine proposed but if dynamic tables is a must-have for you I would consider using Partitioning.
PostgreSQL allows you to create ona main table and few child tables (partitions), records are disjunctive between child tables, but every record from any child table is visible in parent table. This means that you can insert rows into any child table you want using just simple insert statement (its not cool but has the same level of complexity as composing and persisting an entity, so its acceptable in your case) and query database using HQL