Re: [hibernate-dev] [Search] Deprecating the @Key annotation
On 29 January 2015 at 16:25, Gunnar Morling wrote: > 2015-01-29 9:42 GMT+01:00 Hardy Ferentschik : >> >> Hi, >> >> > It would be nice to simply remove the references to @Key in the >> > documentation, and avoid trying to explain when to choose between the >> > two alternatives. >> > >> > This would imply to deprecate the annotation.. any objection? >> >> +1 for not mentioning it in the docs. Not sure whether this implies that >> we need to deprecate it as well, but I have no hard feelings if we do. > > > I wouldn't like to remove it from the docs without deprecating it. It'd > appear as if a) we'd have forgotten to document this stuff or b) it's stuff > where no-one knows it's there and whether it works or not. > > My vote goes for doc removal + deprecation in 5.1., followed by the removal > in 5.2 / 6 (depending on what the project guideline for this sort of change > is). +1, let's say we remove it in 6.. that can be adjusted if need be. Sanne > >> >> --Hardy >> >> ___ >> 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] [Search] Native Java serialization support
Hi, I would like to summarize a discussion we had on IRC to get some more feedback and come to a decision on how to move forward. I am currently in the need of extending our serialization support for the distributed Search deployment scenarios. Basically we are serializing our different LuceneWork instances from slave to master in this case. This includes things like Lucene's Document instances, which are part of add/update operations. Historically, this needs arose with Lucene dropping all serialization support for their classes, so we were forced to implement our custom serialization. To do so we defined an SPI (org.hibernate.search.indexes.serialization.spi.*) and provided two implementations, one based on native Java serialization and one based on Avro [1]. The two implementations are provided as separate artifacts (the serialization/java and serialization/avro modules in our build) and theoretically it should be possible to switch between them by exchanging jar files. I am saying theoretically, since I found out during my recent work, that the Java serialization module is broken at several places. In its current state it would not work (I guess we never noticed since the default is Avro and we do not even document the possibility to change implementation. However, it also shows that no one has even tried). The question is, what do we do now? Do we want two implementations and should the Java serialization be fixed and then extended with the new functionality (btw, I need to serialize DocValues now) or is it time to drop this module, reducing the amount of code we have to maintain and making it a bit easier to implement new serialization requirements. With dropping the module I mean to remove the serialization/java module leaving everything else in place. So you still can write your own serialization implementation, however, we provide no alternative to our preferred choice of Avro (which is afaik considerably faster than native Java serialization which was one of the driving factors of using it). I think on IRC we already "kind of" agreed that we should drop native Java serialization. I just wanted to put it out once more for everyone to comment/vote. --Hardy [1] http://avro.apache.org/ pgpr_YeqHhIGN.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Search] SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT failing on Mac
Hi, for a couple days my master build of Search is broken. The integration test SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT fails: Failed tests: SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT>SearchNewEntityJmsMasterSlave.searchNewMembersAfterSynchronizationOnSlave1:107->SearchNewEntityJmsMasterSlave.assertSearchResult:131 Unexpected number of results from search expected:<1> but was:<0> SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT>SearchNewEntityJmsMasterSlave.searchNewMembersAfterSynchronizationOnSlave2:116->SearchNewEntityJmsMasterSlave.assertSearchResult:131 Unexpected number of results from search expected:<1> but was:<0> SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT.secondLevelCacheShouldBeActive:50 Second level cache not enabled A full build log is here [1]. Does anyone have an idea what it could be. AFAICT this test just extends SearchNewEntityJmsMasterSlave and adds very little to it. Other sub-classes of this test pass. Then again, it is damn hard to tell what is actually supposed to happen and why. I had a quick check of the server log files as well, but nothing which really sticks out, except maybe a JGroups warning about a buffer size. This is all related to the changes for HSEARCH-1324 [2]. As indicated in the subject, this seems to be a Mac problem (Linux works, don't know about Windows). My environment is: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Maven home: /opt/java/maven Java version: 1.7.0_45, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.10.1", arch: "x86_64", family: "mac" Any ideas moving forward? Is it worth the effort to get to the bottom of this or is it a possibility to disable the test? --Hardy [1] https://gist.github.com/emmanuelbernard/853e712094365cee7205 [2] https://hibernate.atlassian.net/browse/HSEARCH-1324 pgpbv7QygDarA.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HHH-3555 Envers Enhancement
We have an EAP 6/Hibernate 4 customer looking for an enhancement for envers for which there is an existing "Closed - Won't Fix" Jira: https://hibernate.atlassian.net/browse/HHH-3555 Before I create an RFE, wanted to make sure there was no obvious reason I shouldn't begin the enhancement request process to look at adding this in a future release. Also, do we have a sense of how much work it might be should we decide to move forward. Thanks! Stephen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Naming and "naming strategies"
So here is what I have for implicit naming strategy, in simplified form: 1. Table naming 1. Entity primary table - @Table 2. Join table - @JoinTable 3. Collection table - @CollectionTable 4. 2. Column naming 1. basic attribute column 2. entity discriminator column 3. tenant id column 4. @Any discriminator column 5. @Any key column 6. @JoinColumn 7. @PrimaryKeyJoinColumn Especially as far as column naming goes, can anyone see any I am missing? On Fri, Jan 23, 2015 at 10:43 AM, Steve Ebersole wrote: > Thanks Max for validating I am not going insane... at least in regards to > this :) > > On Fri, Jan 23, 2015 at 10:19 AM, Max Rydahl Andersen > wrote: > >> On 23 Jan 2015, at 14:18, Steve Ebersole wrote: >> >> [1] - I vaguely recall seeing that certain databases allow different >>> length >>> constraints for different types of identifiers (table name, versus column >>> name, versus constrain name, ...). Can anyone confirm that? >>> >> >> I remember db2 have this fun. >> >> http://bytes.com/topic/db2/answers/183320-maximum-length- >> table-names-colums-etc >> >> I believe Oracle has too but couldn't find evidence for it. >> >> /max >> http://about.me/maxandersen >> > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
