Getting RevisionType

[n.mirzadeh]

Hi,

In case that a revision number is known (e.g. by querying the revision table), and it's desired to get an entity at that revsion along its revision type. How can I do that? I can use, the AuditReader.findRevision(Class<T> revisionEntityClass,Number revision) method which returns the changed entity. How can I determine the revision type? The forRevisionsOfEntity() method would query the revsion-table again, which I don't need!

[adamw]

There's no method currently that gets both the revision entity and a historic entity using one query, you'll have to do two.

Adam

[n.mirzadeh]

I don't know what you're referring as 'historic data', because a revision entity is a historic data. RevisionType is part of the revision entity, and when it is retrieved the revision-type data is filter out. I don't get the reason why this data can't be returned in the same way it is returned by calling the forRevisionsOfEntity() method. Because the later method gets the revision-type data from the revision entity anyway.

[al0]

I am wondering why you cannot obtain a revision type at the same moment when you obtain a revision number.

[n.mirzadeh]

Well, I've described it. For instance, I query version-table for specific date. That returns 'version-info', the revision-type is stored along the revision-entity. For a revision, you can have several changed (revision) entities from different type, and each changed entity has its own revision type.

[al0]

That's true. But for forRevisionsOfEntity() brings you only (likely) small performance  penalty, so why not use it? Does it matter much that the revision-table will be queried again?

BTW, it may be not a bad idea to make an overloaded version of forRevisionsOfEntity() accepting not true/false as the second parameter

• or ResultType enum(ENTITY_ONLY, ENTITY_AND_REVTYPE, ALL). 
• or EnumSet of ResultElement enum (ENTITY, REVISION_TYPE, REVISION_ENTITY)

[n.mirzadeh]

The main reason is the forRevisionOfEntity() method would make a join between an audited-table and the revision-table, which has a performance pentalty. The second is, it is un-necessary, but you need to do it because there's no other way. My argument is, the API should allow the getting of revision type when a revision-entity is retrieved from an audited-table.

[al0]

"The main reason is the forRevisionOfEntity() method would make a join between an audited-table and the revision-table, which has a performance pentalty."

Yes, it would - but the penalty, the most likely, will be small one. Is this operation on a really time-critical path in your application?

As for "should" - rather "might". Too fat API is not good. In this case small change to forRevisionsOfEntity() may help (described in my previous post).

[n.mirzadeh]

In general, when some data is stored in one-table, it "should" be possible to retrieve it when you retrieve a rocord from that table. I will still argue that the type information is stored in audited-entity table, and the API should allow the getting that information. Currently, it is filter out.

[al0]

While in this very case it looks right (at least for me) to have such method, your reasoning is weak.

It does not matter what is stored where - it is an implementation detail which should not (save very rare cases) influence API.

[n.mirzadeh]

As a matter of fact, it is matter what is stored where.

[al0]

OK, this discussion rather does not belong here, but the whole idea of JPA is that you may change detais of a storage structure without affecting your application logic (e.g. change an inheritence strategy). Data would be distributed over the tables differenty - but it would not affect your entities.

If you do not mind to be bound to the storage strusture tightly - use a plain SQL. Otherwise you have to accept some trade-offs.

[adamw]

Ah, you wrote revision type not revision entity - sorry I misread .

So you only want to get the revision type, without the revision entity, am I right?

Btw. I'm not entirerly sure if there's no join with the revision entity if you read just the historic entity anyway.

Adam

[n.mirzadeh]

Hi Adam,

thanks for your reply. What I'd like to do is to retrieve a historic entity along its revision type. I can retrieve the historic entity, but I can't determine the entity was inserted, modified or deleted. Here is my case:

1. query revision-table to get all revisions that are made for a given date.
2. use revsion-entity from the result set obtained in Step 1. and query historic entity, and, show historic data along it type of operation (i.e. insertion, deletion or update) that created the histroic data.

My problem is in order to show the type of operation, i.e. RevisionType, I need to use an API that would make a join between the revision-table and the audited-table. This operation in essence is not needed, and with large audited dataset, would introduce performance penalty.

[al0]

Unless you use some very inefficient DBMS system the penalty likely to be relatively small and hardly noticeable to users of your system.

What is your typical usage scenario - a peeking for the specific entity or listing for all entities in some timerange, anticipated load (requests per second or per minute, ...)?

Have you dione any performace tests that prove your point or you just believe "joins are bad"?