I'm working on a new application, that will be used by dozens of clients, each client also with dozens of users. I really don't want to handle with multiple datasources (because that may lead to performance issues), so I choose to use only 1 database for all tenants, and prepare the application to handle multitenancy through logical data segregation (creating a tenant id with my entities and indexing all tables with this ID).
But, I was wondering, in case of a client need to restore it's backup, in order to prevent the down time of the entire system, is it possible (or viable) to address this problem creating all tables partitioned by tenant id? In this case, can I performe a backup/restore by partition on Oracle?
Yes, backup and restore of table partitions is possible. See here in the documentation: https://docs.oracle.com/database/121/BRADV/rcmresind.htm#BRADV696.
Also see here for examples:
https://www.thegeekdiary.com/oracle-database-12c-new-feature-rman-recover-table/
https://oracle-base.com/articles/12c/rman-table-point-in-time-recovery-12cr1
I am working on a legacy application. It uses java, hibernate. The problem is there are sql joins which are getting executed using Hibernate.
These SQls consists of two tables TableA, TableB. The problem is now TableA moved to database at US and TableB moved to database at UK. Means both are at different locations and different schemas. Now I have to migrate the application so that these joins can be executed.
How can I use this join to fetch the data from these two tables or how to configure hibernate to connect to different databases so that the SQL join can be executed.
According to this Q&A:
Doing a join over 2 tables in different databases using Hibernate
... it cannot be done by Hibernate itself.
The other approach to consider would be to use XA to integrate the database. But that is heavy-weight and not likely to be performant. See this Q&A
What is the 'best' way to do distributed transactions across multiple databases using Spring and Hibernate
... with sums it up like this:
The best way to distribute transactions over more than one database is: Don't.
In your case, this is saying is that you should pull the data from the two tables separately and then "merge" them programatically. Clunky.
Alternatively, have a long hard discussion with management about doing something about your organization's split-brain database problem. (For example, could the UK and US databases each hold read-only snapshots of the other sites business-critical tables?)
Please note that the above is substantially "opinion", but I don't think we can do much better than that. My understanding is that there are no "silver bullet" solutions to this difficult problem.
I spent all of yesterday reading various articles/tutorials on Hibernate and although I am blown-away by how powerful it is, I have one major concern with it.
It seems that the standard practice is to allow Hibernate to design/generate your DB schema for you, which is a new and scary concept that I am choking on. From the tutorials I read, you just add a new entity to your hibernate.cfg.xml config file, annotate any POJO you want with #Entity, and voila - Hibernate creates the tables for you. Although this is very cool, it has me wondering about a handful of scenarios:
What if you already have a DB schema and the one Hibernate wants to generate for you does not conform to it? What if you have a crazy DBA that refuses to budge on the pre-defined (non-Hibernate) schema?
What if you have reference tables with tens of thousands of records in it (like all the cities in the world)? Would you have to instantiate and save() tens of thousands of unique POJOs or is there a way to configure Hibernate so it will honor and not overwrite data already existing in your tables?
What if you want to do perf tuning on your schema/tables? This includes indexing, normalizing above and beyond what Hibernate creates automatically?
What if you want to add constraints or triggers to your tables? Indexes?
I guess at the root of this is the following:
It looks like Hibernate creates and forces a particular schema/config on your DB. I am wondering how this agenda will conflict with our platform standards, our DBA philosophies, and our ability to perf tune/tweak tables that Hibernate interacts with.
Thanks in advance.
I think you're attributing too much power to Hibernate.
Hibernate does have an idiom that may influence database implementation.
Hibernate does not generate a schema for you unless you ask it to do so. It's possible to start with an existing schema and map it to Java objects using Hibernate. But it might not be possible or optimal if the schema conflicts with Hibernate requirements.
If the DBA won't budge - as they shouldn't - or Hibernate can't accomodate you, then you have your answer: you can't use Hibernate.
Your DBA might consent, but your app might find that the dynamic SQL that's generated for you by Hibernate isn't what you want.
Fortunately for you, it's not the only game in town.
I don't think implementations have to be all or none. If you use simple JDBC to access reference data, what's the harm?
Database design considerations should be independent of Hibernate. Constraints, triggers, normalization, and indexes should be driven by business needs, not your middleware choices.
If you don't have a solid object model, or the schema can't accomodate it, then you should reconsider Hibernate. There's straight JDBC, stored procedures, Spring JDBC, and iBatis as alternatives.
Hibernate comes with a default way to map objects to tables - like several tools/libraries, it favours convention over configuration for simplicity.
However, if you want to map the entities to database tables differently, you can explicitly tell Hibernate how these are mapped (from simple attributes such as changing the table name, through to redefining the foreign-key relationships between related entities and how this is persisted).
If you do this correctly, you don't need to instantiate and save existing data, as this would be pointless - the database already contains the information about the entities in exactly the form that Hibernate understands. (Think about it - to load and then immediately save an entity should always be a no-op, and so can be skipped altogether.)
So the short answer to your question is "no". If you don't care for designing tables, you can let Hibernate adopt a reasonable default. If you do want to design your schema explicitly though, you can do this and then describe that exact schema to Hibernate.
As someone who's worked on java and hibernate in the enterprise for a long time, I have seen very few projects which use this capability. You'll see some build tools and other things do this, but for a real enterprise app, i've never seen this.
Most DBA's won't let the application user create tables. They rely on a privileged user to do those things, and the user that the app connects as would have r/w privs on the data but not the schema itself.
As a result, you write the SQL yourself, and you do the hibernate mappings to match. It doesn't mean your object design won't influence your SQL, but you should still always create your schema upfront.
No. You can use hibernate tools to generate the entities from existing database.
There are 2 ways you can go about in using Hibernate. If you have good DBA or database designer, then it is better to design the database and then map it into hibernate.
On the other hand if you don't have DBA and have good developer then let Hibernate generate Database for you.
The concept behind Hibernate is to map Database and the Objects. So it is called as ORM (Object-Relational Mapping) tool.
Read here for Object Relational Impedance.
This is the preferred way for a quick'n dirty prototype or a simple tutorial, but it's far from being the preferred way for any production application. I largely prefer designing the database independently, using scripts to generate the schema, tables, views, indexes, etc., and map the schema to entities.
As long as the mapping finds the tables and columns in the database, everything is fine.
As soon as you have data in your database and the schema must change, you'll have to write migration scripts anyway. You can't just drop everything and restart from scratch. The tutorials are written for developers starting with Hibernate and who must discover Hibernate as quick as possible, without dealing with complex SQL scripts.
What if you already have a DB schema ...
I don't know where you get that impression. Hibernate can use existing schema. It is quite flexible.
What if you have reference tables ...
Make the relationship LAZY, and it won't load automatically. Only changed object will be saved.
What if you want to do perf tuning ...
Just don't use the generated schema. It is just a starting point. You can customize as you need.
What if you want to add constraints or triggers to your tables? Indexes?
Some as above.
You can use hibernate with an existing database schema.
You can use various annotations to map to existing tables and columns, for example:
#Table(name = "dbschema.dbTable") - should be placed before your class file to map it
#Column(name = "colName") - to map a column
Just be sure that the hibernate is configured with this option:
hibernate.hbm2ddl.auto=update
If you set this to create it will create the schema, so do not do this in your case.
Use hibernate/jpa when appropiate. A common practice when designing apps is to extract the draft and alter it manually after needs (indices etc). However, it will be a pain for you if you change the db layout from hibernate way to do things. Lots of the beauty of JPA will be lost. For tasks which require heavy performance tuning and full control - just go for reguar jdbc.
Some answers:
A. It is possible to add an index annotation : see the table annotation.
B. If you have reference tables, you may choose to have lazy fetching or eager fetching (i.e - if your tables represent a person and a its books - whether to load a person without its book, or with its books)
C. Hibernate can be used to work on existing schema. The schema might not be trivial to work with , but as other have said, you should design db only according to business needs, and not according to framework conventions
D. I would like to encourage you also to read what hibernate does "under the hood" - it uses lots of usage of proxies, which hurts performance, you must understand well the scope of session , and the usages of 1st level and 2nd level cache .
E. Following what I wrote at section D - working with triggers will cause your DB to change "under the hood" when it comes to hibernate. Consider a case where updating a record will create (using a trigger) an entry in some archiving table , and let's say this table is also annotated via hibernate - your hibernate caching will not be aware of the change that happend outside of the application scope.
F. It is important to me to state that I'm not against Hibernate, but you should not use it for all solutions, this is a mistake I did in the past. I now work with Spring-JDBC and I'm quite pleased (for our application needs it will be hard to use Hibernate, and I assume we will consider this only in the case we need to support more than one DB flavor).
The answers to my previous post encouraged me mixing SQL and NoSQL db.
What is the best practice implementation of two databases in terms of application context configuration and DAO creation?
Let's choose Derby as the SQL db and Cassandra as the other one. What I am searching for is e.g. an example appcontext.xml, two DAOs, one implementing CRUD on Derby and the other one ond Cassandra and one (not two) sample unit test using both DAOs simultanously.
Tutorials, sample (maven ;-) ) projects, book recommenditions etc. welcome.
Try spring-data http://www.springsource.org/spring-data (an introductory reference video here)
i think Spring Data JPA provides a repository programming model that starts with an interface per managed domain object. May be we can switch or point domain to different data stores. i haven't tried out this by myself. You can check getting-started-with-spring-data-jpa
but combining nosql and relational will be complex. but one can persist certain type of data into one store based on the its segregation level. i am not sure the transaction isolation possible for multiple data stores.say you store documents to one store and relational data to one which requires data integrity if needed.
I have two tables in two separate Oracle databases (not schemas) that I need to join in Hibernate. Currently, I have two Hibernate sessions going out to the separate databases. Before anybody says look at Hibernate Shards, I have spent a better part of a day looking at that sub-project and have found that: it is for horizontal partitioned data (all the tables must be in all of the databases AFAIK), there is no way for one to tell Shards to look only in one database (Hibernate Shards Docs), and is no longer being worked on.
Things that I have thought about to try to solve this problem:
Doing a findAll() or some restricted variant of that on both of the tables, and manually doing the join using some loops. (Ok for very small tables - prohibitive from small tables on up)
Have the sessions do some kind of interaction (I have no idea if this is even feasible - will have to look at the Hibernate Session API)
Removing the database name from the URL string of different hibernate-xxxx.cfg.xml and insert them into the separate hbm.xml files like this:
<class name="foo" table="foo_table" schema="foo_schema" catalog="foo_db">
(Doesn't seem to work from my initial tests and that seems like truck sized security hole)
Use the Repository Pattern (Unsure if my Java-Fu is strong enough)
Is there something that I'm overlooking in one of the cases above or can it be another way that I haven't listed above?
You have a couple of problems unfortunately.
Hibernate does not supporting joining across multiple "physical" database instances
Out of the box, most database don't support joining across multiple "physical" database instances
Fundamentally DBs are only good/performant at joining tables that are in the same database. There are ways of joining across databases but if the size of both tables is big this can be a problem, and peformance may suffer. Do some googling on "oracle join across database" and you'll find some pointers on how to do this but it involves fiddling around with Oracle create a virtual link from one DB to the other.
I would consider either doing the join in memory, if you are comfortable the data set will fit within the memory constraints AND you are only doing this in one special case.
If you'll need to do different joins between these two databases then I would go for a more permanent solution, like the Oracle linking above.
I have no experience with doing this myself, but I know that Oracle supports database "links" between two separate database instances. Maybe this article will help you?
Post on Hibernate forums about using Oracle link between two instances