1 2 Previous Next 25 Replies Latest reply on Nov 15, 2010 2:14 PM by fbascheper

entityNames in envers

hernanbolido Aug 24, 2010 2:03 PM

Hello!

We realized that for fully supporting entityNames in envers, it would be necessary to incorporate some issues, besides modifications already done.

These issues are useful for envers users, who are using the dto pattern for carrying information to a front end application.

In order to avoid carrying the whole historic model to the front end application, DTOs contains “references” to objects instead of real objects (i.e. a lazyness solution at DTO level). However, in this scenario, it is necessary to know the entityName of each “lazy” object for building those references.

I was thinking about the tasks we should carry out to achieve a solution (I´ve already done some of these changes):

Giving support to obtain the entityName for an object inside the graph (for root object is trivial)
- Add a new cache for id, rev,object -> entityName in FistLevelCache.
- Open AuditReader API for getting entityName for a given envers object (i.e. an object previously retrieved by envers). This feature is supported in CORE through Session API.

Add the method >>isEntityNameAudited() to the class AuditReader.

Giving support to obtain the NOT_AUDITED relationships. I see two different solutions (and prefer the second one):

There should be a way to ask Envers if an object reference is a NOT_AUDITED one. Then, ENVERS users will use it to get this associated objects via CORE.
The method AuditReader>>find() look up the associated instance via core for every relationship configured as NOT_AUDITED. Do the same for the getEntityName() method. In this solution, ENVERS users doesn’t care about this type of relationahips.

What do you think about this?

Regards. Hernán.

1. Re: entityNames in envers

adamw Aug 25, 2010 3:00 AM (in response to hernanbolido)

I would also vote for option 2. All changes sound good to me.

Waiting for the patches then

Adam
Actions
2. Re: entityNames in envers

hernanbolido Sep 7, 2010 2:38 PM (in response to adamw)

Hello!

I´ve been working on this issue and I've some question/doubts:

If find() methods from AuditReader are capable of retrieving the objects audited by a NOT_AUDITED relation (option 2 of my last post), the "throws NotAuditException" won´t be semantically correct anymore, because those methods would check the not_audited relationships before returning or throw a different exception in other case. If we pick up this solution, Envers users that are currently catching the NotAuditedException should do a code refactor; they should ask if the relationship is audited or not before using the method instead of catching the exception.
Another way to solve the problem and avoid the migration, is to add new findSomethingElse() methods to AuditReader. Then, users who need this feature should call them instead of the currend find() methods.
I prefer the last solution. Could someone suggest a proper name to those methods? Something better than >>findHistoricAndCurrent()

Another question is: I´m testing my changes on all active branches (trunk, 3.5 and the old 3.3). Does it make sense to give you the three patches?

Regards. Hernán.
Actions
3. Re: entityNames in envers

hernanbolido Sep 20, 2010 3:44 PM (in response to hernanbolido)
Hello!

Here is the patch for this issue. There are 3 files, one per branch.
I've created the tests for testing it

I decided to name the new methods findAll(), but let me know if you have a more suitable name.

I hope it will help.

Regards. Hernán.

patchEntityNames-BRANCH_3.3.txt.zip 7.8 KB

patchEntityNames-BRANCH_3.5.txt.zip 6.7 KB

patchEntityNames-TRUNK.txt.zip 6.7 KB
Actions
4. Re: entityNames in envers

hernanbolido Sep 23, 2010 8:40 AM (in response to hernanbolido)

Hi!

I've created the jira issue for this -> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5588
Actions
5. Re: entityNames in envers

fbascheper Sep 23, 2010 1:39 PM (in response to hernanbolido)

Hi,

I've taken a quick look, but it would be great if you could also add documentation for the Envers reference manual; preferably as a separate patch.

Kind regards,
Erik-Berndt
Actions
6. Re: entityNames in envers

hernanbolido Sep 23, 2010 3:45 PM (in response to fbascheper)

Hi,

What do you think can be documented and where would be the correct place to put it?
I've never worked with hibernate documentation, besides building it using maven's goal. Where can I find what to use for edit the documentation?

Regards. Hernán.
Actions
7. Re: entityNames in envers

fbascheper Sep 24, 2010 5:35 AM (in response to hernanbolido)

The Envers refence manual is currently available at http://docs.jboss.org/hibernate/envers/3.6/reference/en-US/html_single/
Wouldn't it be good to expand chapter 5 with this new query api?

The manual is built from hibernate svn, look in /documentation/envers (if I'm not mistaken).

Regards, Erik-Berndt
Actions
8. Re: entityNames in envers

hernanbolido Sep 24, 2010 8:57 AM (in response to fbascheper)

Hi,

I think that que query section is not the correct place because this new methods are part of the find() methods family. Maybe there is a whole missing section in the documentation for "loading historical objects" if we want to give a good explanation.
What do you think?

Regards. Hernán.
Actions
9. Re: entityNames in envers

fbascheper Sep 24, 2010 10:31 AM (in response to hernanbolido)

Actually, you're right. I'm not sure though if this would require a new chapter, or that we count integrate all supported query methods in one chapter with several sections. Perhaps you could propose a chapter setup?
Actions
10. Re: entityNames in envers

hernanbolido Sep 28, 2010 12:07 PM (in response to fbascheper)

Hi!

Taking a look at hibernate core's documentation, I saw that chapter 10 has the following structure:

10. Working with objects
    10.1. Hibernate object states
    10.2. Making objects persistent
    10.3. Loading an object
    10.4. Querying
        10.4.1. Executing queries
        10.4.2. Filtering collections
        10.4.3. Criteria queries
        10.4.4. Queries in native SQL
    10.5. Modifying persistent objects
    10.6. Modifying detached objects
    10.7. Automatic state detection
    10.8. Deleting persistent objects
    10.9. Replicating object between two different datastores
    10.10. Flushing the Session
    10.11. Transitive persistence
    10.12. Using metadata

Can we follow this idea and propose something like:

5. Working with historical objects
     5.1 Loading a historical object (explain the find methods here)
     5.2 Mapping a class more than once (explain support for entityNames)
     5.3 Querying
          5.4 Explain all query options for envers
          5.5 ...

What do you think?

Regards. Hernán.
Actions
11. Re: entityNames in envers

fbascheper Oct 1, 2010 2:50 AM (in response to hernanbolido)

Yes, that's exactly what I meant.
I would be great if you could create a patch for the documentation (against current trunk) and attach it to the issue .

Regards,
Erik-Berndt
Actions
12. Re: entityNames in envers

fbascheper Oct 1, 2010 3:21 AM (in response to fbascheper)

Assuming you meant 5.3.1 Explain query options for envers (instead of 5.4)
Actions
13. Re: entityNames in envers

hernanbolido Oct 1, 2010 9:13 AM (in response to fbascheper)

You're right. I meant 5.3.1.

I will work on it and come back with the patch.

Regards, Hernán.
Actions
14. Re: entityNames in envers

adamw Oct 7, 2010 2:37 AM (in response to hernanbolido)

Sorry for jumping in so late, but there's one thing I don't quite understand - if there's a isEntityClassAudited/isEntityNameAudited, why do we need a findAll method? Users can check if an entity is audited or not and use and auditReader or an entityManager, or do I miss some use-case?

Adam
Actions

1 2 Previous Next

Go to original post