File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Override/Extend EJB3.x

 
Akaine Harga
Ranch Hand
Posts: 97
Java MyEclipse IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone,

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...
 
Akaine Harga
Ranch Hand
Posts: 97
Java MyEclipse IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Still trying to solve this... =S
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33696
316
Eclipse IDE Java VI Editor
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not use a database view for the selects? Then the view has that extra where clause.

The insert, update and "delete" would still need to know about them. But you should only have that in one place anyway.
 
Akaine Harga
Ranch Hand
Posts: 97
Java MyEclipse IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
E Armitage
Rancher
Posts: 989
9
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Akaine Harga
Ranch Hand
Posts: 97
Java MyEclipse IDE Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm.. generic finder (saver/deleter/updater)... great idea! Thanks =)
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic