wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Override/Extend EJB3.x Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Override/Extend EJB3.x" Watch "Override/Extend EJB3.x" New topic
Author

Override/Extend EJB3.x

Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 79

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...

Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
willCodeForFood("Java,PHP,C#,XML,VBS,XHTML,CSS,JavaScript,SQL"); //always looking for job opportunities in AU/NZ/US/CA/Europe :P
Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 79

Still trying to solve this... =S
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30146
    
150

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 79

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

Joined: Mar 17, 2012
Posts: 892
    
    9
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

Joined: Nov 03, 2009
Posts: 79

Hmm.. generic finder (saver/deleter/updater)... great idea! Thanks =)
 
wood burning stoves
 
subject: Override/Extend EJB3.x
 
Similar Threads
JPA 2.0:Columns inserted as nulls while the table have multiple foreign keys
save my application
HQL Group different tables?
Dynamic table jQuery sort adding old rows