Obtaining @Version value

[lukasj]

I want to suggest that a future release of the JPA API provides a means to get the value of an entities version attribute.

Example: em.getVersion(myEntity);
he
Justification: Generic frameworks like JAX-RS or Servlets might have an interest in getting the value of the version attribute without "knowing" which is "the version attribute" for any particular entity. For example, JAX-RS or Servlets want to send a ETag header to a client for any entity, but the Servlet does not "know" the class of that entity. Like when class name and primary key value are provided by a HTTP request. In that case, a solution would be em.getVersion(myEntity) which just should return the value of the version.

[lukasj]

@glassfishrobot Commented
Reported by mkarg

[lukasj]

@glassfishrobot Commented
mkarg said:
An improvement ontop would be em.isCached(Class<?>, id, version) which returns true or false, depending on the fact whether the EM has an entity with that primary key and version in cache.

Justification: To answer conditional HTTP requests it would be great to query the cache for a particular version. If the cache does not contain that version, EM shall NOT load from disk, but answer to JAX-RS or Servlet that this entity is not there.

[lukasj]

@glassfishrobot Commented
pbenedict said:
I think this is more of a design issue than a needed JPA enhancement. If you want to generate ETag values off any entity, for example, you should create integration logic that knows how to do the transformation. I don't understand why you want to avoid having to know the version attribute; it's not poor design to expose it. Just go ahead and create a universal interface that all your versioned entities can implement:

public interface Versioned {
    int getVersion();
}

PS: Caching is supported now by JPA 2.0 @Cacheable; this should alleviate your concern about always materializing an entity.

[lukasj]

@glassfishrobot Commented
mkarg said:
By design, I do not want to add a superfluous interface: JPA already knows the attribute, so it makes no sense to add another interface, as your compiler cannot guarantee that it accesses the same attribute as the annotation uses – risk of hard to track bugs! ALso, the attribute might be invisible to the accessing package on design purpose and adding an interface enforces "public" visibility. You simple will copy existing technology for the sake of not adding a needed JPA feature.

Also my proposal will work with ANY entity – even entities that the caller has no source code of, hence, cannot add the proposed interface!

@Cacheable actually does not solve the described use case. I do want to load from disk exactly in case the ETag is not matching. @Cacheable(false) prevents this.

[lukasj]

@glassfishrobot Commented
pbenedict said:
That is an interesting requirement. I've always been in control of my entities so I haven't encountered your dilemma. If the version isn't being exposed to you in a third-party entity, there may be a good design reason for that (or not). Someone from the EG should opine. I think the question boils down to this: For any given entity, is the value contained in a @Version attributed considered to be intrinsically public? If so, then expose it through the EM.

[lukasj]

@glassfishrobot Commented
mkarg said:
Yes, in fact our application provides services upon any "unknown" set of entities provided by third parties: We accept JPA QL and we return entities – without care of the entity classes, its interface, or its source. Hence we need to be able to handle their version without deeper knowledge, but solely must go through an JPA API.

BTW, we do not see that the @Version member implicitly has to be public, as we do not want to access the member. We only want to either ask the EM to expose the version value, or even better, simply ask whether a known version still is current or not.

[lukasj]

@glassfishrobot Commented
neilstockton said:
This requirement seems reasonable to me, and is already available in the JDO API. In JDO you can also have a surrogate version (i.e no field in the class, but the version managed by the persistence solution). That would also be a useful requirement for JPA (FWIW)

[lukasj]

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-74

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/74
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[kalgon]

Shouldn't a getVersion(entity) method be added to the PersistenceUnitUtil class where there's already a getIdentifier(entity) method? In the meantime, emf.getMetamodel().entity(entityType).getVersion().getJavaMember() could be used.

[gavinking]

This is a reasonable-enough request, and there's been some low-level activity on this issue, so check out #451.