• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Override/Extend EJB3.x

 
Ranch Hand
Posts: 99
MyEclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 99
MyEclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Still trying to solve this... =S
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 99
MyEclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 99
MyEclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm.. generic finder (saver/deleter/updater)... great idea! Thanks =)
 
incandescent light gives off an efficient form of heat. You must be THIS smart to ride this ride. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic