Re: [hibernate-dev] [Search] OSGi split packages
Hi, My 2 cents as an end user of Search: just move them. It's really not a big deal if it's compilation errors and we just have to reorganize the imports: we clearly see the errors when we upgrade so we can fix them easily. You just put it prominently in the release notes and it's OK. Most of our problems when we upgrade don't come from API changes but from deeply hidden regressions. It's where we spend a lot of time (yeah I have one to diagnose today on a 4.3 -> 4.4 upgrade :)). -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Bytecode enhancement
Hi Guillaume, A Maven plugin for build time enhancement of entities is coded up. Not without a few problems along the way. But I think we are there now. Comments are in-lined with your questions. There should be a plugin in the maven repo soon (if not now) using a Mojo and the necessary descriptors declaring dependencies. pull/669 The documentation has a PR waiting to merge showing users how to configure for Ant, Maven or Gradle. Look at https://github.com/hibernate/hibernate-orm/pull/667 for configuration information going into the reference manual. Jeremy On 03/19/2014 04:25 PM, Guillaume Smet wrote: > Hi, > > I took a look at the bytecode enhancement Maven plugin and I also have > this issuehttps://hibernate.atlassian.net/browse/HHH-8833 . > > As far as I can tell the Maven plugin (and I suppose the Gradle plugin > too) doesn't provide any information about the classpath so it's > impossible to use the bytecode enhancement plugin in real life > applications because you obviously have dependencies to other classes. https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-enhance-maven-plugin/hibernate-enhance-maven-plugin.gradle https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-gradle-plugin/hibernate-gradle-plugin.gradle Are there more dependency declarations you needed ? > > Is this something supported or something very experimental? I found > some old posts of Emmanuel discouraging the use of bytecode > enhancement so I'm not sure it's a good idea to invest our time in it? > > Basically, we have a lot of nullable @OneToOne properties and as far > as I understood it, it's supposed to help this case a lot. > > Maybe using something like > http://www.mograblog.com/2010/01/setting-classloader-in-maven-plugin.html > might be a good idea for the Maven plugin? > > Anyway feedback welcome before we invest time in it. > > Thanks. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
Hi, Before 4.4, when you add a @ContainedIn to a property without the corresponding @IndexedEmbedded, they were still added and taken into account in the dependency resolution which was quite useful to declare dependencies between entities without having an explicit @IndexedEmbedded which are useless in some of our cases. Starting with 4.4, they are simply ignored. I've spent some time to understand why and here it is: https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L686 -> you can see that the @Contained is added even if there is no corresponding @IndexedEmbedded In the new code, the @Contained annotation is added in updateDepthProperties which is conditioned by the fact that there is a corresponding @IndexedEmbedded: https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L711 https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L731 https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L755 I'm wondering if it's a desired change or just an overenthusiastic refactoring? We used the old behavior in several projects so we would really like to see it back if it is the latter. And if it's the former, we would like to discuss it :). Thanks for your feedback. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] OSGi split packages
On 26 Mar 2014, at 20:52, Sanne Grinovero wrote: > Emmanuel, could you elaborate of what you have in mind as "scalability > reasons”? Scale as in having more event provider sources (ORM, Infinispan, X, Y, Z). But we could accept that ORM has historical and privileged rights and will keep the root package. > >> org.hibernate.search.SearchFactory -> >> org.hibernate.search.spi.SearchFactory > > as Emmanuel said, that's an API currently. I'm inclined to think we > should convert it to an SPI, and provide a richer more ORM specific > version in the ORM module? > That way, we could keep the package name. It would break things for > Infinispan Query API but it seems that would happen anyway. And each event source would need a SearchFactory subinterface + some delegator implementation? Is that your idea? Because SearchFactory contains very useful cross event source methods like retrieving an analyzer, accessing Lucene directly and providing access to the query DSL. That could work. I am a little concerned about documentation. > "You can use SearchFactory but it’s InfinispanSearchFactory or > OrmSearchFactory or… depending on what you use Hsearch for” It will make documentation mix and reuse harder. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] OSGi split packages
On 27 Mar 2014, at 11:18, Emmanuel Bernard wrote: > >> >>> org.hibernate.search.SearchFactory -> >>> org.hibernate.search.spi.SearchFactory >> >> as Emmanuel said, that's an API currently. I'm inclined to think we >> should convert it to an SPI, and provide a richer more ORM specific >> version in the ORM module? >> That way, we could keep the package name. It would break things for >> Infinispan Query API but it seems that would happen anyway. > > And each event source would need a SearchFactory subinterface + some > delegator implementation? Is that your idea? > Because SearchFactory contains very useful cross event source methods like > retrieving an analyzer, accessing Lucene directly and providing access to the > query DSL. > > That could work. BTW SearchFactory would still remain an API by that factor. - o.h.s.boostrap.SearchFactory - o.h.s.boostrap.CommonSearchFactory ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0) but as we also have @ContainedIn on transient methods, we can't work around it totally. As usual we are committed to work on a test case and fix once we agree it should be fixed. On Thu, Mar 27, 2014 at 11:03 AM, Guillaume Smet wrote: > Hi, > > Before 4.4, when you add a @ContainedIn to a property without the > corresponding @IndexedEmbedded, they were still added and taken into > account in the dependency resolution which was quite useful to declare > dependencies between entities without having an explicit > @IndexedEmbedded which are useless in some of our cases. > > Starting with 4.4, they are simply ignored. > > I've spent some time to understand why and here it is: > https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L686 > > -> you can see that the @Contained is added even if there is no > corresponding @IndexedEmbedded > > In the new code, the @Contained annotation is added in > updateDepthProperties which is conditioned by the fact that there is a > corresponding @IndexedEmbedded: > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L711 > https://github.com/hibernate/hibernate-search/blob/4.3/engine/src/main/java/org/hibernate/search/engine/spi/AbstractDocumentBuilder.java#L731 > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/engine/metadata/impl/AnnotationMetadataProvider.java#L755 > > I'm wondering if it's a desired change or just an overenthusiastic > refactoring? > > We used the old behavior in several projects so we would really like > to see it back if it is the latter. > > And if it's the former, we would like to discuss it :). > > Thanks for your feedback. > > -- > Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
On 26 Jan 2014, at 22:29, Steve Ebersole wrote: > BTW, here is the topical guide I have started for this: > https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc Very good start. Missing the more complicated cases with explicit class leave specified access type and overrides on the attributes, but it for sure helps understanding the whole concepts. Really like the idea of topical guides more and more. I think they are not only valuable for users of ORM, but also for us. They document assumptions/behaviour which help understanding decisions made in the code. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Metamodel, Jandex and "XML mixins"
On 27 Jan 2014, at 04:29, Steve Ebersole wrote: > I was looking into some failures on master in regards to XML overrides for > JPA annotations in relation to our friend Access/AccessType. Which got me > to thinking... > > How does the "mixin" code handle defining the target for the > AnnotationInstances it creates? AFAIK it needs to look at two things, the ‘access’ attribute of the persistence unit and the ‘access' attribute of the entity node. Based on that it should create an AnnotationInstance with the appropriate AnnotationTarget. Once these pseudo annotation are created the processing of the mapping information is the same as with actual annotation defined on the entities (metadata-complete needs to be handled here as well in a sense that if a xml mapped entity is metadata-complete, existing AnnotationInstances based on actual annotations must be removed). That’s how it should work. However, this was Strong’s baby. Maybe he could shed some more light on this. > Seems to me this code would have really no idea whether to choose the field > or the getter as the target. Which is potentially problematic as we are > validating the "placement" of these annotations. It does, based on the ‘access’ attribute (see above) —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "derived identifier" mapping
No idea. I think Emmanuel had a better understanding of the derived identifier
logic.
On 27 Jan 2014, at 06:26, Steve Ebersole wrote:
> What's the rational for supporting the following?
>
>
> @Entity
> class Product {
>...
> }
>
> @Entity
> class Order {
>...
> }
>
> @Entity
> @IdClass(...)
> class OrderLine {
>@Id
>private Order order;
>
>@Id
>private Product product;
> }
>
> Specifically, the declaration of the OrderLine primary key. Why would
> these not have to be `@Id @ManyToOne`?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] OSGi split packages
On 26 Jan 2014, at 23:11, Sanne Grinovero wrote: > On 26 March 2014 20:18, Hardy Ferentschik wrote: >> >> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote: >> >>> The classes in the ORM module are extremely widely used by our primary >>> target: >>> >>> - FullTextQuery >>> - Search >>> - FullTextSession >>> >>> and two more lesser ones, but I think the 3 above are probably "THE >>> API”. >> >> That was my thinking as well. >> >>> To move these out of the way we'd at least need to postpone the >>> OSGi work for after a Beta to include a deprecated version of these. >> >> ? I don’t get what you are saying here. Deprecate it in an Alpha in order >> to then move them in a Beta release? That makes no sense what soever to me. >> My take on this is, that we are dealing with a new major version of Search >> and that we are still in Alpha phase. If we need to make non backwards >> compatible changes we should do it now. > > If we need to change public API we have the obvious options: > 1# just break the API > 2# deprecate the old one > > I didn't mean that we stricly should do 2#, but we should at least try hard > ;-) > But *if* we go for 2#, we should keep the deprecated classes around > for at least a Beta release, or the effort (of keeping them) is not > worth it as I think an Alpha release is not going to inspire enough > confidence, or have enough visibility, for us to suggest using it as a > migration milestone. I just don’t get your migration milestone idea. I doubt seriously that many users have the time and resources to gradually upgrade from let’s say a 4.x version to 5.0.0.Alpha1, 5.0.0.Beta1, … 5.0.0.Final. There might be some early adopters and contributors who are interested in Search, but in most cases I would expect people to wait at least until a CR and then do a direct upgrade. Also you approach seems to me against my understanding of the different release steps towards a Final. I would use the Alpha releases to actually make the breaking changes and getting more stable once we get to Beta. In your approach things would still work in let’s say Beta1, but then get removed for Beta2 or even a CR. For me that’s contradictive. Personally I also the deprecations as a tool to keep backwards compatibility between final releases, not between intermediate releases working towards a final. For me the question is, do we see a future of Search in OSGi and do we want to invest into making Search fully OSGi enabled or not. If so we should just go ahead and resolve these split packages. If we don’t see OSGi as so important we should just add the minimum of metadata information to the artefacts and use the Require-Bundle workaround and be done with it. > Problem is, that if we keep them you might not be able to finish the > OSGi issue, as it requires these classes to be removed. Well, I guess since the alternative classes would exist at the time of deprecation, we would export them from the bundle, ignoring the deprecated ones. > Or maybe we can relax this requirement temporarily? I guess the important > milestone to aim at is to define the final API? What do you mean with define API. For me the API is defined. We are not making changes to the API as such. > I guess we shouldn’t necessarily aim at fully resolving HSEARCH-1465 in a > single tag, Not me either. HSEARCH-1465 is the container issue for all OSGi related tasks. HSEARCH-1560 is just one of the sub tasks which imo needs to be resolved in one go. >> Mind you, we are talking just about an import statement change. No API >> or functional change. And yes, our downstream projects would need to adjust. > > I get that. Still a nice self-documenting deprecated class is so much > easier to handle than an import statement change. Except, that deprecations can be ignored. Not that many developers pay careful attention to the build log and depending on how much logging the build does it might just disappear in the noise. So when will the user actually notice the change? When we remove the deprecated class! At some stage the users of Search need to adjust their imports. I’d rather let them handle a couple of compilation failures and be done with it. >>> I think I like Hardy's approach of moving from Engine better; not >>> least we can provide alternative deprecated constants in the ORM >>> module for ORM users to use as a migration help (Environment and >>> ProjectionConstants). >> >> ? > > You could make a copy of Environment and ProjectionConstants in the > ORM module, and deprecate it to document the new position. Maybe we > shouldn't invest too much into backwards compatibility, but since this > is a trivial step we should just do it. -1 >> I like it. In fact I wish cfg would have been called configuration in the >> first place. >> Having both, cfg and configuration seems odd to me. In this case I prefer to >> just >> use cfg > > Same here. I almost suggested to rename all of _cfg_ to > _configuration
Re: [hibernate-dev] [Search] OSGi split packages
On 27 Jan 2014, at 09:17, Guillaume Smet wrote: > It's really not a big deal if it's compilation errors and we just have > to reorganize the imports: we clearly see the errors when we upgrade > so we can fix them easily. You just put it prominently in the release > notes and it's OK. My thinking exactly. > Most of our problems when we upgrade don't come from API changes but > from deeply hidden regressions. It's where we spend a lot of time > (yeah I have one to diagnose today on a 4.3 -> 4.4 upgrade :)). +1 Thinking back to my time as pure Search user or user of any library, handing the move of classes was never a big issue. Maybe a bit annoying, but basically a no brainer. It becomes tricky if the actual API or behaviour changes. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
On 27 Jan 2014, at 11:03, Guillaume Smet wrote: > Before 4.4, when you add a @ContainedIn to a property without the > corresponding @IndexedEmbedded, they were still added and taken into > account in the dependency resolution which was quite useful to declare > dependencies between entities without having an explicit > @IndexedEmbedded which are useless in some of our cases. What exactly do you mean with "taken into account in the dependency resolution”? Maybe a full example would help here. > I'm wondering if it's a desired change or just an overenthusiastic > refactoring? It might be. Still trying to understand what you are saying and the full implications. In particular I am wondering where a @ContainedIn without the matching @indexedEmbedded makes sense. Custom bridges come to mind in this case. Are you using a custom class or field bridge in this case? If not, I don’t understand what purpose the @ContainedIn would fulfil. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
On 27 Jan 2014, at 11:35, Guillaume Smet wrote: > FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0) > but as we also have @ContainedIn on transient methods, we can't work > around it totally. > > As usual we are committed to work on a test case and fix once we agree > it should be fixed. I think an example/test would be awesome. Then we have some concrete example to base our discussion upon. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
On 26 March 2014 20:20, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 21:07, Steve Ebersole wrote: > >> I also renamed @AccessType (out custom one) to be @AttributeAccessor to >> better avoid confusion with the JPA names. > > +1 Definitely the better choice I don't argue with that, but the context of my example was "assuming my team has the convention of always putting mappings on properties", so in such a case I'd want to use the second. I really have no strong feeling against how you all think it should be or any spec wording, my only concern is what happens when someone does have a different interpretation or opinion. AFAIK today these are ignored: would be nice to eventually be able to strictly validate (for whatever decison you might take). I think that's important to be taken into consideration while you work on how Jandex reads things: to be able to provide strict validation, you will need to be able to read annotations from both positions. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Move container integration test to a separate default test cycle
> My vote goes to #1 as well for the short term. +1 > we need to share the running containers across > modules, or merge the integration tests in a single module per > container. > Not sure how far Maven will be a problem for this I think it would be easier to start and download the containers without using maven and then run the maven build assuming that everything needed is already downloaded and started. On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero wrote: > My vote goes to #1 as well for the short term. > > There also is a third option, which requires some more work but > provides a very nice balance. > A great deal of the slowness of this complex matrix execution can be > addressed to the continuous startup and teardown of services like the > various databases and the datastores. > > Considering that each of those services starts in less than a second, > the problem is not the single startup but literally the compound > effect of the complex matrix: if we started say MongoDB, and CouchDb, > and all others, and all containers at the beginning of the suite, we > could then run matrix tests in a very efficient way, I'd bet we could > keep the full matrix *and* the testsuite under a single minute. The > goal would be to reuse a single WildFly (or EAP) startup to test on > each database; i.e. we need to share the running containers across > modules, or merge the integration tests in a single module per > container. > Not sure how far Maven will be a problem for this. > > For the OGM needs to test on EAP, I just dicussed with Davide (same > office today), and since we'd be testing an old version of EAP > (6.1.0.Alpha1 being the latest in public Maven repositories), our idea > is that this is too old to be useful anyway. We'll set up a profile - > disabled by default - which downloads and tests latest EAP to be used > by the Jenkins instance running at Red Hat. > > Sanne > > > On 25 March 2014 09:25, Emmanuel Bernard wrote: > > This is a follow up on > > > https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092 > > > > We keep piling up new backends, new containers to test and new rules > > checked at build time. A consequence is that it is becoming less and > > less pleasant to work on OGM. > > > > You can see that n version of Naked+WF+EAP+... multiplied by m backends > > simply will make this project horrendously slow to contribute to. > > I imagine n = 3 or 4 and m = 10 in a medium term. > > > > I see two options that would keep us around for a while: > > > > 1. Make the container integration tests only run with a specific option > >activated on the CI. > > 2. Move the container integration tests outside in a different repo > >altogether. > > > > I do prefer 1. > > > > Emmanuel > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] OSGi split packages
On Thu 2014-03-27 12:40, Hardy Ferentschik wrote: > > the tricky part is that today SearchFactoryIntegrator extends > > SearchFactory, but since SearchFactoryIntegrator needs to say in > > Engine, it can't depend on SearchFactory. What would you think of > > breaking this parent-child relation? > > From a user's perspective they wouldn't be able to narrow down their > > SearchFactory to an SearchFactoryIntegrator, but we could provide an > > unwrap backdoor. I am not following you. You no longer want a common SearchFactory interface usable across all event source implementations? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Regression with @ContainedIn between 4.3 and 4.4
Hi Hardy, On Thu, Mar 27, 2014 at 12:52 PM, Hardy Ferentschik wrote: > I think an example/test would be awesome. Then we have some concrete example > to base our discussion upon. I don't think a test would be useful to understand what we do. Here are a few additional information about our business case. The fact is that we have complex business rules which requires us to reindex entities when we change/index one even if they don't have an @IndexedEmbedded relation. You're right about having specific fieldbridges but we also have the case when we want to index the results of a transient method on a dependency of the object. In one of our (many) examples of this usage, we have: ProductModel @ContainedIn Set articles; ProductArticle doesn't have an @IndexedEmbedded annotation on its ProductModel field because we don't use this feature to index it. But when we reindex a ProductModel, we need to reindex the articles. Moreover, an article might have a ShootingBrief and when we change the ProductModel, we also want to reindex the ShootingBriefs of the ProductArticles as they have a field which depends on a ProductModel property. This field is the result of a transient method. Not an @IndexedEmbedded thing. Using @ContainedIn as we do allows us to build a dependency graph of indexing. And this dependency graph exists even if we don't use @IndexedEmbedded but other Search features (FieldBridges, @Field on a transient method...). Note that it worked perfectly until 4.4. I don't know if it's more clear with these information. Feel free to ping me on IRC to discuss it further if needed. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote: > > I don't argue with that, but the context of my example was "assuming > my team has the convention of always putting mappings on properties", > so in such a case I'd want to use the second. > Like I said, I could really live with either interpretation. The sole reason I lean towards #1 is the idea of consistency. If you start allowing @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different semantic depending on where you find it (class versus attribute). As I am writing the topical guide, I am realizing there are really 3 questions involved here: 1) How do I determine what is (versus is not) a "persistent attribute"? 2) Where do I look for mapping annotations for each persistent attribute? 3) How do I access persistent attribute values at runtime? This is really where we all (and not just us...) have varying opinions. Like you think (1) and (2) should be handled distinctly, whereas the rest of us (iiuc) think that (1) and (2) should be determined via the same logic. Further, you see the (1)/(2) combo as distinct from (3). To you @Access(FIELD) on the getter is fine because of this; there @Access(FIELD) is merely identifying the style of runtime access. Not saying either is right or wrong. I just think it helps to better understand where/why we all agree/disagree. Which ultimately gives us better understanding in these discussions. > I really have no strong feeling against how you all think it should be > or any spec wording, my only concern is what happens when someone does > have a different interpretation or opinion. AFAIK today these are > ignored: would be nice to eventually be able to strictly validate (for > whatever decison you might take). > > I think that's important to be taken into consideration while you work > on how Jandex reads things: to be able to provide strict validation, > you will need to be able to read annotations from both positions. > For sure. This is one of the things metamodel is striving to do better than before in regards to recognizing and warning about misplaced annotations that will be ignored. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "derived identifier" mapping
This code is 8 years old so no I did not remember.
I did some archeology. The Git migration slots all of that history so I
had to fire up svn.
svn checkout
https://svn.jboss.org/repos/hibernate/annotations/branches/v3_4_0_GA_CP/
svn annotate src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java
svn log -r 11058
src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java
svn log | grep -C 3 ANN-492
Anyways, it is related to the following:
https://hibernate.atlassian.net/browse/HHH-4259
https://hibernate.atlassian.net/browse/ANN-492
https://forum.hibernate.org/viewtopic.php?t=967202&start=0&postdays=0&postorder=asc&highlight=
It looks like a combination of the following:
- the old code was not able to get the annotation metadata from the
entity. It was getting the metadata from the id class. Against the
spec but it was a tough bug to fix
- Goeffrey had a problem and contributed the test
- the test passed a future version of annotations when I applied it
- I left it here as coverage
On Thu 2014-03-27 11:59, Hardy Ferentschik wrote:
> No idea. I think Emmanuel had a better understanding of the derived
> identifier logic.
>
>
>
> On 27 Jan 2014, at 06:26, Steve Ebersole wrote:
>
> > What's the rational for supporting the following?
> >
> >
> > @Entity
> > class Product {
> >...
> > }
> >
> > @Entity
> > class Order {
> >...
> > }
> >
> > @Entity
> > @IdClass(...)
> > class OrderLine {
> >@Id
> >private Order order;
> >
> >@Id
> >private Product product;
> > }
> >
> > Specifically, the declaration of the OrderLine primary key. Why would
> > these not have to be `@Id @ManyToOne`?
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
On Thu, Mar 27, 2014 at 5:36 AM, Hardy Ferentschik wrote: > > On 26 Jan 2014, at 22:29, Steve Ebersole wrote: > > > BTW, here is the topical guide I have started for this: > https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc > > Very good start. Missing the more complicated cases with explicit class > leave specified access type and overrides on the attributes, but it for > sure helps understanding the whole concepts. > Hence the phrase "started" ;) > Really like the idea of topical guides more and more. I think they are not > only valuable for users of ORM, but also for us. They document > assumptions/behaviour which help understanding > decisions made in the code. Definitely. Good documentation/guides are for more than users. They help us as developers understand the expectations and intentions. They act as "organizational memory". And they help us write and debug tests wrt those expectations and intentions. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "derived identifier" mapping
So this is another representation of a choice we are having to make quite a
bit in 5.0 development... correctness versus "legacy", which has really
implications for users. So if users are relying on this Hibernate
"feature" of splitting identifier mapping annotations between the entity
and the IdClass, their apps would break if we now start supporting this
"the correct way".
Maybe this is another case where we can log warning for "misplaced"
annotations when we see an IdClass with persistence mapping annotations.
The spec makes no mention of use cases where an IdClass has mapping
annotations, nor do I consider this a "usability feature" from the users
perspective (aside from the mentioned compatibility concerns).
FWIW, I took these tests and changed the mappings to instead use @Id
@ManyToOne on the entity itself. Metamodel understood that perfectly
well...
On Thu, Mar 27, 2014 at 8:58 AM, Emmanuel Bernard wrote:
> This code is 8 years old so no I did not remember.
> I did some archeology. The Git migration slots all of that history so I
> had to fire up svn.
>
> svn checkout
> https://svn.jboss.org/repos/hibernate/annotations/branches/v3_4_0_GA_CP/
> svn annotate
> src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java
> svn log -r 11058
> src/test/java/org/hibernate/test/annotations/cid/OrderLinePk.java
> svn log | grep -C 3 ANN-492
>
> Anyways, it is related to the following:
>
> https://hibernate.atlassian.net/browse/HHH-4259
> https://hibernate.atlassian.net/browse/ANN-492
>
> https://forum.hibernate.org/viewtopic.php?t=967202&start=0&postdays=0&postorder=asc&highlight=
>
> It looks like a combination of the following:
>
> - the old code was not able to get the annotation metadata from the
> entity. It was getting the metadata from the id class. Against the
> spec but it was a tough bug to fix
> - Goeffrey had a problem and contributed the test
> - the test passed a future version of annotations when I applied it
> - I left it here as coverage
>
> On Thu 2014-03-27 11:59, Hardy Ferentschik wrote:
> > No idea. I think Emmanuel had a better understanding of the derived
> identifier logic.
> >
> >
> >
> > On 27 Jan 2014, at 06:26, Steve Ebersole wrote:
> >
> > > What's the rational for supporting the following?
> > >
> > >
> > > @Entity
> > > class Product {
> > >...
> > > }
> > >
> > > @Entity
> > > class Order {
> > >...
> > > }
> > >
> > > @Entity
> > > @IdClass(...)
> > > class OrderLine {
> > >@Id
> > >private Order order;
> > >
> > >@Id
> > >private Product product;
> > > }
> > >
> > > Specifically, the declaration of the OrderLine primary key. Why would
> > > these not have to be `@Id @ManyToOne`?
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
Here is how I phrase this atm in the topical guide: [NOTE] It is important to understand that generally speaking the phrase "access type" refers to a number of concepts: * Determining which fields/methods constitute a persistent attribute. * Indicating where to look for mapping annotations. * How the attribute (its value) is accessed at runtime For the most part, Hibernate treats all 3 as being the same. There are some caveats here, which we will cover as we go along. On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole wrote: > > > > On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote: >> >> I don't argue with that, but the context of my example was "assuming >> my team has the convention of always putting mappings on properties", >> so in such a case I'd want to use the second. >> > > Like I said, I could really live with either interpretation. The sole > reason I lean towards #1 is the idea of consistency. If you start allowing > @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different > semantic depending on where you find it (class versus attribute). > > As I am writing the topical guide, I am realizing there are really 3 > questions involved here: > 1) How do I determine what is (versus is not) a "persistent attribute"? > 2) Where do I look for mapping annotations for each persistent attribute? > 3) How do I access persistent attribute values at runtime? > > This is really where we all (and not just us...) have varying opinions. > Like you think (1) and (2) should be handled distinctly, whereas the rest > of us (iiuc) think that (1) and (2) should be determined via the same logic. > > Further, you see the (1)/(2) combo as distinct from (3). To you > @Access(FIELD) on the getter is fine because of this; there @Access(FIELD) > is merely identifying the style of runtime access. > > Not saying either is right or wrong. I just think it helps to better > understand where/why we all agree/disagree. Which ultimately gives us > better understanding in these discussions. > > > >> I really have no strong feeling against how you all think it should be >> or any spec wording, my only concern is what happens when someone does >> have a different interpretation or opinion. AFAIK today these are >> ignored: would be nice to eventually be able to strictly validate (for >> whatever decison you might take). >> >> I think that's important to be taken into consideration while you work >> on how Jandex reads things: to be able to provide strict validation, >> you will need to be able to read annotations from both positions. >> > > For sure. This is one of the things metamodel is striving to do better > than before in regards to recognizing and warning about misplaced > annotations that will be ignored. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
Here is what I am trying to decide between in terms of support for this.
Mainly this is a usability matter for me. Part of usability is how easily
we can explain this so users can understand and use it. To me there are 2
paths to high usability here...
== Consistency
The first path would be to be consistent in what "access type" means and
its implications. For example, to me that would mean at the beginning of
this topical guide I can make the following statement truthfully, then to
me we have consistency:
A persistent attribute is defined as either FIELD or PROPERTY access (in
strict JPA sense). FIELD access means that:
1) A persistent attribute is identified by its Class field
2) The mapping annotations for the persistent attribute are located on the
Class field
3) At runtime we access the persistent attribute's value directly via the
field.
PROPERTY access means:
1) A persistent attribute is identified by its JavaBeans-style getter and
setter on a Class
2) The mapping annotations for the persistent attribute are located on the
Class getter method
3) At runtime we access the persistent attribute's value via the
getter/setter methods.
>From there its just a matter of rules for "which" wins at the various
levels (hierarchy, class, attribute).
== ItJustWorks
This is more the proposal of Sanne iiuc. Here, "where to look for mapping
annotations" is irrelevant; the idea being that we'd look both on the field
and the getter and "merge" the metadata. Another implication here is that
@Access explicitly identifies how they are accessed at runtime (and I'd
assume this in turn drives the recognition of what are the persistent
attributes).
There is definitely a beauty here in that the rules are again pretty simple
to explain and understand. The thing that worries me is the part about
"merging" the metadata. Sanne gave some simple examples of where this
would possibly be difficult. But there are others, some even more
difficult. One that immediately jumps to my mind is "plural" annotations;
for example:
@ManyToOne
@JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
private Person person;
@ManyToOne
@JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
public getPerson() { return person; }
Is this 4 join-columns? 2? Error?
I think at the very least we should be enforcing that the annotations
appear consistently (either all on field or all on getter) for a given
attribute *if* we were to go this route.
On Thu, Mar 27, 2014 at 9:50 AM, Steve Ebersole wrote:
> Here is how I phrase this atm in the topical guide:
>
>
> [NOTE]
>
> It is important to understand that generally speaking the phrase "access
> type" refers to a number of concepts:
>
> * Determining which fields/methods constitute a persistent attribute.
> * Indicating where to look for mapping annotations.
> * How the attribute (its value) is accessed at runtime
>
> For the most part, Hibernate treats all 3 as being the same. There are
> some caveats here, which we will cover
> as we go along.
>
>
>
>
> On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole wrote:
>
>>
>>
>>
>> On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote:
>>>
>>> I don't argue with that, but the context of my example was "assuming
>>> my team has the convention of always putting mappings on properties",
>>> so in such a case I'd want to use the second.
>>>
>>
>> Like I said, I could really live with either interpretation. The sole
>> reason I lean towards #1 is the idea of consistency. If you start allowing
>> @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different
>> semantic depending on where you find it (class versus attribute).
>>
>> As I am writing the topical guide, I am realizing there are really 3
>> questions involved here:
>> 1) How do I determine what is (versus is not) a "persistent attribute"?
>> 2) Where do I look for mapping annotations for each persistent attribute?
>> 3) How do I access persistent attribute values at runtime?
>>
>> This is really where we all (and not just us...) have varying opinions.
>> Like you think (1) and (2) should be handled distinctly, whereas the rest
>> of us (iiuc) think that (1) and (2) should be determined via the same logic.
>>
>> Further, you see the (1)/(2) combo as distinct from (3). To you
>> @Access(FIELD) on the getter is fine because of this; there @Access(FIELD)
>> is merely identifying the style of runtime access.
>>
>> Not saying either is right or wrong. I just think it helps to better
>> understand where/why we all agree/disagree. Which ultimately gives us
>> better understanding in these discussions.
>>
>>
>>
>>> I really have no strong feeling against how you all think it should be
>>> or any spec wording, my only concern is what happens when someone does
>>> have a different interpretation or opinion. AFAIK today these are
>>> ignored: would be nice to eventually be able to strictly validate (for
>>> whatever decison you might take).
>>>
>>> I think
Re: [hibernate-dev] "derived identifier" mapping
On 27 Jan 2014, at 15:17, Steve Ebersole wrote: > So this is another representation of a choice we are having to make quite a > bit in 5.0 development... correctness versus "legacy", which has really > implications for users. So if users are relying on this Hibernate "feature" > of splitting identifier mapping annotations between the entity and the > IdClass, their apps would break if we now start supporting this "the correct > way". > > Maybe this is another case where we can log warning for "misplaced" > annotations when we see an IdClass with persistence mapping annotations. +1 > The spec makes no mention of use cases where an IdClass has mapping > annotations, nor do I consider this a "usability feature" from the users > perspective (aside from the mentioned compatibility concerns). +1 —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Another @Access quandry
On 27 Jan 2014, at 19:36, Steve Ebersole wrote:
> Here is what I am trying to decide between in terms of support for this.
> Mainly this is a usability matter for me. Part of usability is how easily we
> can explain this so users can understand and use it. To me there are 2 paths
> to high usability here...
>
>
> == Consistency
>
> The first path would be to be consistent in what "access type" means and its
> implications. For example, to me that would mean at the beginning of this
> topical guide I can make the following statement truthfully, then to me we
> have consistency:
>
>
> A persistent attribute is defined as either FIELD or PROPERTY access (in
> strict JPA sense). FIELD access means that:
> 1) A persistent attribute is identified by its Class field
> 2) The mapping annotations for the persistent attribute are located on the
> Class field
> 3) At runtime we access the persistent attribute's value directly via the
> field.
>
> PROPERTY access means:
> 1) A persistent attribute is identified by its JavaBeans-style getter and
> setter on a Class
> 2) The mapping annotations for the persistent attribute are located on the
> Class getter method
> 3) At runtime we access the persistent attribute's value via the
> getter/setter methods.
>
>
> From there its just a matter of rules for "which" wins at the various levels
> (hierarchy, class, attribute).
My vote goes to consistency.
> == ItJustWorks
>
> This is more the proposal of Sanne iiuc. Here, "where to look for mapping
> annotations" is irrelevant; the idea being that we'd look both on the field
> and the getter and "merge" the metadata. Another implication here is that
> @Access explicitly identifies how they are accessed at runtime (and I'd
> assume this in turn drives the recognition of what are the persistent
> attributes).
>
> There is definitely a beauty here in that the rules are again pretty simple
> to explain and understand. The thing that worries me is the part about
> "merging" the metadata. Sanne gave some simple examples of where this would
> possibly be difficult. But there are others, some even more difficult. One
> that immediately jumps to my mind is "plural" annotations; for example:
>
> @ManyToOne
> @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
> private Person person;
>
> @ManyToOne
> @JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
> public getPerson() { return person; }
>
> Is this 4 join-columns? 2? Error?
>
> I think at the very least we should be enforcing that the annotations appear
> consistently (either all on field or all on getter) for a given attribute
> *if* we were to go this route.
Right, that would be the minimum requirement.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Attribute paths and '.' versus '#' as separator
This is a bit of a potentially insidious one. Not the best way to start off a discussion, I know :) The premise is this... Until now Hibernate has represented attribute roles using dots. For an attribute named 'department' on the com.acme.Employee entity, the role would be "com.acme.Employee.department". In terms of embeddables, say Employee had an 'address' embedded with its own attributes like 'city'. Then, the full role for 'city' would be "com.acme.Employee.address.city". As you can start to see the dots here are completely indistinguishable in terms of those which define the package/class and those which identify the attribute "path". So one of the things I started playing with in 5 is to replace the separators used in attribute paths to use '#', such that "com.acme.Employee.address.city" would instead be "com.acme.Employee#address#city". This makes the role fully parseable which is actually useful in quite a few situations. And it REALLY helps in things I have just started working on like storing metadata for composites (embeddeds/embeddables) on the SessionFactory, which is the first step in support for some cool new features around embeddables like discriminated inheritance support. However, there is a minor drawback. Like all attributes, collections have a role. Unfortunately the use of '.' in their role Strings leaks into the SPI in terms of locating the CollectionPersisters. So the question is whether to continue with this path of replacing the use of '.' with '#' for attribute path separators. The drawback is unfortunate. The benefit is very nice, but I can't really say it is required atm. Votes? Thoughts? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors
After pulling, I am getting a failure executing :hibernate-core:runAnnotationProcessors. I tried building with --debug and it looks like the hibernate-core/target/generated-src/apt/main is deleted without being re-generated. When hibernate-core is compiled, there are failures because package org.hibernate.hql.internal.antlr does not exist. Anyone have ideas why this is happening? Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
