Emmanuel. Thank you for your help and your suggestions. They are greatly appreciated, but I'm afraid the view won't work.
In oracle, the instant you join 2 tables, you can no longer write to the view, especially across to both tables. You won't be able to insert new data into both tables.
http://download-east.oracle.com/docs/cd ... sthref2945
Regarding your previous post:
Quote:
Just because in 99% of my usecase I need the country name, does not mean that I want to set the country name in the user object rather than a separated country object.
But the problem is we do want to set it on the user object. The problem is that you're forcing us to create 2 domain models: one that we'll actually expose, and another one that is TIGHTLY coupled with our database and designed to get around the weaknesses of the current SecondaryTable specification. We now need adapters so a user can pass a sensible object to our API and then we, behind the scenes, copy all the values from the sensible object into beans designed to work around Hibernate's seemingly strange limitations.
For my employer, I am working on a very large project that is doing that now. Realistically, the performance hit is not perceptible, but it's rather challenging to document as well as explain to others. The bottom line is that this 2 layered adapter approach works and scales decently, but I'd much rather write a complex mapping than maintain 3 times the number of classes needed.
For my case, I need about 10 domain object. I have 35 tables representing these objects. I have 35 classes mapping to these tables. I have 10 adapter classes transforming the sensible objects to the hibernate objects. The users of my API only know about the 10 domain objects.
You seem to be advocating exposing the 35 class layer to the user. Therefore, I am stuck, for the entire life of my API, with the table layout I have now, due to the tight coupling. If I want to change the underlying table structure, I have to either build an adapter layer or completely modify the API.
The ideal would be to have an optimized domain model with a complex mapping and letting hibernate handle all the joins across as many tables as needed. Since I'm working in an enterprise environment, dozens of developers from multiple divisions and companies will be using my API. The simpler I make it, the less I have to troubleshoot it after it's released and the greater the probability it'll be used correctly by our users.
Correct me if I'm wrong, but one of the biggest intentions of a persistence technology, such as Hibernate, is to ensure that our application developers can manipulate data objects that make sense to them and our DBAs can organize their tables in a manner that makes sense to them. The Java developer shouldn't know anything about the structure of the underlying database in an ideal world. This is especially relevant in enterprise scenarios, such as mine, where the database will be used by more than one technology, such as reporting software, or different custom applications.