As Brett finishes up the "unified schema" work I wanted to start discussion about some simplifications that could/should come from that.
Jandex, scanning and discovery One of the outcomes of moving to Jandex to process annotations is the requirement that we have a good Jandex Index available to us. There are 2 parts to this: 1. We need a "baseline Index". This can be a Jandex Index passed to us (by WildFly, e.g.). But in cases where we are not passed one, we need to build one. 2. We then augment the Index with "virtual annotations" built from XML mappings. As I said, in the cases we are not handed a Jandex Index we need to build one. Currently this is a tedious process handled by manually indexing all known classes (known from a few different sources). But this need to know the classes to index them is problematic. Which got me to thinking that it sure would be nice to tie this in to the scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already such that as we walk the "archive" we automatically add classes we encounter to the Index. I'd actually add things to the Index whether or not they are supposed to be managed classes (exclude-unlisted-classes). There are lots of benefits to this. And not just to ORM, provided we start sharing the Jandex with Search (etc) as we have discussed. This better ensures that all needed classes are available in the Index. This allows better discovery of "ancillary" classes via annotation. Etc... Technically this one is not tied to the unified schema work, we could do this change today. The difference is that the move to the unified schema means that everything is processed using Jandex, so having that good Index becomes even more important. There is one difficulty I see here. Assuming we are to only use listed-classes, that means classes explicitly listed in the PU *and* classes listed in XML. Checking that a class is listed in the PU is simple, but checking whether a class comes from XML before we use it is not as straightforward. Its not impossible, just another thing to consider. Applying XML defaults orm.xsd allows specifying attribute specific defaults. One such default, e.g., is access. What happens in the current annotation "mocking"[1] is that the default access is only applied to attributes that are referenced in the XML. If the XML is used in an "override" way and an attribute is defined in the entity with annotations but is not mentioned in the XML, the default access from the XML is not picked up, as it should be (unless the annotations define a more local explicit access). I think the solution is to expose all the 'persistence-unit-defaults' values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab them from there. -- seems to me there were others I wanted to discuss, but they escape my mind at the moment ;) [1] I think we all dislike the term "mocking" here. I'd like to start discussing alternatives. I mentioned "augmentating" above, I like that one. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
