[hibernate-dev] JPA 2.1 progress

[Hardy Ferentschik]

On Jul 17, 2012, at 2:42 PM, Steve Ebersole wrote:

> On 07/17/2012 04:58 AM, Hardy Ferentschik wrote:
>> 
>> On Jul 16, 2012, at 9:06 PM, Steve Ebersole wrote:
>> 
>>> One such point of discussion was a common interface for "Index".
>>> Unfortunately the name Index is already taken as in the main Jandex
>>> class.  So we came up with some other names.  For this work I went ahead
>>> with the name 'IndexResult' for that common contract (interface).
>>> Anyway, no matter the name, eventually both Index and that new
>>> CompositeIndex would both implement this new common contract.
>> 
>> Why do you need this contract? What benefit do you gain?
> 
> We want to re-use what JBoss AS would hand us, so we need an interface.  The issue is that AS creates an Index per module, it then aggregates them together in a "composite index".  Hibernate would need access to this aggregation/composition.  AS already has this class.  We are just applying a common contract over the 2.  It also allows wrapping the "index" in annotation overrides, if thats the route we end up wanting/needing to go.

Thanks for the info. I was missing this info and it gives "composite index" a different meaning as well.
In the composite index is there a way to only query for annotation of a given module? Say we get a composite index
and are supposed to build the configuration. In our code we can just get for example all named queries by getting the corresponding
annotations from the index. If you have a composite index you might have to consider whether the class hosting the annotation is
part of the persistence unit you are processing. 

>>> The other thing we discussed was integrating XML overrides into the
>>> indexing process since quite a few places where Jandex gets used would
>>> need this.  And since you worked on that in the metamodel codebase, was
>>> hoping to get your feedback as to whether you thought it would be
>>> possible to integrate XML overrides into this process up front.
>> 
>> IMO it does not matter so much whether you do the overrides before or after
>> annotation processing. It kind of makes sense to do it afterwards, because the
>> xml configuration normally overrides existing annotations, so replacing an AnnotationInstance
>> in the annotation based index with a pseudo AnnotationInstance reflecting xml
>> configuration seems "natural".
>> 
>> The problem of course is that a Jandex index is immutable and I cannot just replace/modify
>> an AnnotationInstance. For that reason you have to a lot of collection iterations/copies.
> 
> You just hit on one of the exact reasons to do this.  Not that we want an index to be mutable.  I think having them immutable is probably the right choice.  But having additional collections hanging around in memory, not to mention the multiple processing of those collections is what would be good to avoid.

Sure. I get that. 


>> If one wanted to improve on this I could imagine building some sort of OverrideIndex up front
>> containing the pseudo AnnotationInstances from the XML configuration. This OverrideIndex
>> would be generic and could be part of Jandex to be used by other projects. This index could be
>> passed prior to Jandex prior to the annotation discovery phase. For every annotation the discovery
>> index could query the OverrideIndex whether an override exists for a given annotation. If so this
>> override would be added. The benefit of this approach is of course that I don't have to build
>> multiple indexes.
> 
> I think a confusion might be that I am not asking to be able to hand Jandex an XML file and expecting it to be able to "figure out" how XML overriding works as it reads annotation information.  No, there would need to be some sort of SPI between Jandex and Hibernate (or other interested libraries) that directed Jandex how/if/when to apply an override.

That's what I have in mind as well. Basically what I tried to outline.

--Hardy