-
1. Getting RevisionType
adamw May 16, 2011 2:18 PM (in response to n.mirzadeh)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
-
2. Re: Getting RevisionType
n.mirzadeh May 17, 2011 7:29 AM (in response to adamw)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.
-
3. Getting RevisionType
al0 May 18, 2011 3:30 AM (in response to n.mirzadeh)I am wondering why you cannot obtain a revision type at the same moment when you obtain a revision number.
-
4. Getting RevisionType
n.mirzadeh May 18, 2011 3:52 AM (in response to al0)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.
-
5. Getting RevisionType
al0 May 18, 2011 4:33 AM (in response to n.mirzadeh)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)
-
6. Getting RevisionType
n.mirzadeh May 18, 2011 7:36 AM (in response to 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. 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.
-
7. Getting RevisionType
al0 May 18, 2011 7:59 AM (in response to 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."
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).
-
8. Getting RevisionType
n.mirzadeh May 18, 2011 8:57 AM (in response to al0)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.
-
9. Re: Getting RevisionType
al0 May 18, 2011 9:54 AM (in response to n.mirzadeh)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.
-
10. Getting RevisionType
n.mirzadeh May 18, 2011 10:58 AM (in response to al0)As a matter of fact, it is matter what is stored where.
-
11. Getting RevisionType
al0 May 18, 2011 1:34 PM (in response to n.mirzadeh)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.
-
12. Getting RevisionType
adamw May 20, 2011 10:39 AM (in response to n.mirzadeh)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
-
13. Re: Getting RevisionType
n.mirzadeh May 26, 2011 5:16 AM (in response to adamw)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:
- query revision-table to get all revisions that are made for a given date.
- 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.
-
14. Re: Getting RevisionType
al0 May 26, 2011 6:14 AM (in response to n.mirzadeh)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"?