[hibernate-dev] [Search] Handling of mutual dependency with Infinispan
Now that finally Infinispan moved to build (and require) Java7, I'm preparing to upgrade the Lucene Directory to Apache Lucene 4.8. Sometimes it's trivial, some others we're out of luck and this is one of such situations: the new Lucene code expects some new methods to create and validate a CRC32 checksum signature of the Directory segments. Not too annoying - I can handle the coding - but it highlights an old problem which is coming back. Currently Infinispan is still using Hibernate Search 4.5, and provides a Lucene Directory for both Lucene versions 3 and 4. The current build provides the LuceneV4 support as an extension of the V3 source module; this is a hack we introduced a year ago to make sure we'd eventually be able to upgrade to Lucene4 and I was hoping now to finally remove this fishy workaround as I initially expected it to be a temporary measure. But in practice such an upgrade of today would have been impossible: Infinispan also depends on Hibernate Search. Having two different modules in Infinispan is what enables us today to start an update to a new version of Lucene. I'm wondering if we should move the Lucene Directory code into Hibernate Search; this also has licensing implications as that's using ASL2 currently. And that's probably only moving the problem one step down, as Infinispan Query still depends on Hibernate Search (engine) and the Lucene Directory would still depend on Infinispan Core. I'm not having a solution in mind; obviously we wouldn't have such a problem if each of our projects *always* guaranteed a clean migration path via default methods and deprecated methods, but this is a rule which is occasionally broken: when it happens, the only thing I can think of is that one of the two projects needs to release a tag which has some broken components. For example, Infinispan to release occasionally without the Query engine. Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Handling of mutual dependency with Infinispan
I am not sure I understand everything you said. how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC? Be careful, 20 mins run fast in practice :) On 12 May 2014, at 17:38, Sanne Grinovero wrote: > Now that finally Infinispan moved to build (and require) Java7, I'm > preparing to upgrade the Lucene Directory to Apache Lucene 4.8. > > Sometimes it's trivial, some others we're out of luck and this is one > of such situations: the new Lucene code expects some new methods to > create and validate a CRC32 checksum signature of the Directory > segments. > Not too annoying - I can handle the coding - but it highlights an old > problem which is coming back. > > Currently Infinispan is still using Hibernate Search 4.5, and provides > a Lucene Directory for both Lucene versions 3 and 4. > The current build provides the LuceneV4 support as an extension of the > V3 source module; this is a hack we introduced a year ago to make sure > we'd eventually be able to upgrade to Lucene4 and I was hoping now to > finally remove this fishy workaround as I initially expected it to be > a temporary measure. > > But in practice such an upgrade of today would have been impossible: > Infinispan also depends on Hibernate Search. Having two different > modules in Infinispan is what enables us today to start an update to a > new version of Lucene. > > I'm wondering if we should move the Lucene Directory code into > Hibernate Search; this also has licensing implications as that's using > ASL2 currently. And that's probably only moving the problem one step > down, as Infinispan Query still depends on Hibernate Search (engine) > and the Lucene Directory would still depend on Infinispan Core. > > I'm not having a solution in mind; obviously we wouldn't have such a > problem if each of our projects *always* guaranteed a clean migration > path via default methods and deprecated methods, but this is a rule > which is occasionally broken: when it happens, the only thing I can > think of is that one of the two projects needs to release a tag which > has some broken components. For example, Infinispan to release > occasionally without the Query engine. > > Sanne > ___ > 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] Handling of mutual dependency with Infinispan
On 12 Jan 2014, at 18:15, Emmanuel Bernard wrote: > I am not sure I understand everything you said. Same here. > how about you take 20 mins tomorrow during our Hibernate NoORM team meeting > on IRC? > Be careful, 20 mins run fast in practice :) +1 That meeting is at 16:00, right? Need to see whether I can make it, otherwise I suggest a separate meeting. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Reserved words
As of 4.2.12, there are some identifiers that no longer work when used in HQL/JPQL, e.g. [1]. Is there a list of reserved words somewhere? Thanks, Gail [1] https://hibernate.atlassian.net/browse/HHH-9154 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Reserved words
Not really. In general any token whose text is explicitly given in any of the grammars will be treated as a keyword. Generally speaking this is merely an oversight when someone alters the grammars. However, the definition of the OBJECT token actually hasn't changed since the SVN migration. The parameter rule (and its uses) however has changed much more recently... HHH-5126. This was a change you made Gail. One of the major improvements in the next gen parser is the move to "soft keywords", where keywords are contextually recognized which essentially removes the concept of a "reserved word". We use that in a limited fashion in the current grammars. As for this particular report, do we have a simplified test? The Jira just lists the query. On Mon, May 12, 2014 at 2:20 PM, Gail Badner wrote: > As of 4.2.12, there are some identifiers that no longer work when used in > HQL/JPQL, e.g. [1]. > > Is there a list of reserved words somewhere? > > Thanks, > Gail > > [1] https://hibernate.atlassian.net/browse/HHH-9154 > ___ > 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] @MappedSuperclass, @Embeddable and consistency
The JPA spec is completely silent on inheritance when it comes to embeddable classes. When Emmanuel was first developing hibernate-annotations we decided to allow the use of @MappedSuperclass to be extended to embeddable classes to control the persistence of attributes when an embeddable had a superclass. I want to make sure we are all supporting this consistently. And if not, whether we need to revisit that original decision. For example, Gail has recently found inconsistencies in regards to how envers handles @MappedSuperclass + @Embeddable, compared to ORM. Specificaly it has different expectations for audited attributes for @MappedSuperclass when it comes to @Entity versus @Embeddable. Adam/Lukasz. do you guys see that as a conscious decision? If so, can you validate why y'all decided to go that way? If it was not a conscious decision, are there major technical/implementation hurdles to overcome in making this consistent? In Search, OGM, etc are we consistent with this interpretation of @MappedSuperclass + @Embeddable? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
