I've been having this idea for some time. I doubt it's new but still I've found no related info after an extended search.
The idea is to automate database regs logical status management by abstracting it on the java level. To simplify the gibberish I've just wrote I'll give an example.
Let's suppose we have a database table representing some physical entity, cars for example:
where "deleted" would be a boolean field representing a logical deletion of a registry.
When I delete some registry in my app I do not want to actually delete it, just change the "deleted" value to "TRUE" to avoid database relations breakdown. It's a pretty common approach for all relational databases when there is a need to maintain some historical data.
The main part of the application woks with "active" data only (deleted=FALSE), since we do not want to visualize the already deleted data. So to achieve this in every single query we have to manually add the WHERE cars.deleted=FALSE clause. This can become a problem when there are constant database modifications (creation of new relations/tables), dozens of similarly controlled tables and a big development team where communication of every change in the database is just impossible.
In theory this problem could be solved by overriding or extending the session beans processors with some logic to add the necessary clauses to the custom/generated JPAQL expressions, so we would not need to specify the logical deletion parameter every time we want to read some data.
Let's see the classical autogenerated findAll method following the car table example:
After execution this method returns the whole car table including the "deleted" regs. And the simplest way to avoid the deleted data would be to add the following to the JPAQL query string:
What I want is to avoid the last manual change making the framework to add the clause automatically.
So the question is: 1. Are there any ways I could achieve this without rewriting every session bean method? Maybe it's possible to override the JPA query processor like it's commonly done in Hibernate generic DAOs...
Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
Akaine Harga wrote:The idea was to include the "common" fields in all operations without extra database structure or per method modifications. I'm talking about a real EJB wrapper/extension.
Jeanne's advice was actually very good. Use the right tool for the right job.
Also, JPA with N DAO classes for N entities does not scale in development. Shun away from autogenerated methods and ask yourself if you really need a different finder just to filter on a different property. Now apply the same to entities. If you had a schema with 100 entities would you really write 100 finder methods? So if you solve persistence once and use a generic finder then you have one place to apply your common filters.