Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Adrian Nistor
I'd name this directory 'Buster', after the most important (non-human) supporting character from the show Myth Busters. Buster is a crash test dummy that takes damage with a dumb smile on his face, much like our ram dir. It's most prominent feature is that it forgets everything until next run,

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Sanne Grinovero
-1 for "ephemeral" and "volatile", they are pretty much synonyms of "ram" with all the same possible confusions, even to the point of looking like being the recommended choice for "ephemeral class" machines on openstack. "unreliable": it's not unrelaiable as it's actually very reliable and to be r

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Gunnar Morling
I'd argue you can keep the name, if it's in the test JAR. If people still use it in their production code, well... Otherwise, how about "ephemeral"? 2017-05-18 19:05 GMT+02:00 Sanne Grinovero : > On 18 May 2017 at 17:31, Gunnar Morling wrote: >> Can't you just move it to the test JAR if it's for

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Guillaume Smet
Volatile? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Davide D'Alto
+1 for moving it in the test library Neo4j uses the term "impermanent" for its testing db. I'm not a big fun of the "testing" in the name because it does not convey the main characteristics of the directory; it only tells that you should not use it in production (why is it included in the main li

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Sanne Grinovero
On 18 May 2017 at 17:31, Gunnar Morling wrote: > Can't you just move it to the test JAR if it's for testing only? Interesting idea, we can try that as well. I'd still want to set the name straight though. Let's agree on a name first. > > Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" : > >

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Gunnar Morling
Can't you just move it to the test JAR if it's for testing only? Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" : Right technically it's not a unit test. But I'd like to focus on the testing aspect, as "local-ram" might still convey concepts as "fast", maybe even expect it to engage Infinisp

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Sanne Grinovero
Right technically it's not a unit test. But I'd like to focus on the testing aspect, as "local-ram" might still convey concepts as "fast", maybe even expect it to engage Infinispan's off-heap capabilities, or just being an option to consider for other reasons. "testing" ? On 18 May 2017 at 17:20,

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Adrian Nistor
I agree, but probably "unit-testing" is not such a good name either. Technically, that's a functional test. I think I like "local-ram" better, implying that it is not shared/distributed and it is also volatile. On 05/18/2017 06:07 PM, Sanne Grinovero wrote: > As anyone who's bothered to read the

[hibernate-dev] 6.0 proposal - CollectionTuplizer

2017-05-18 Thread Steve Ebersole
As part of removing most Type sub-types we are left with the question of how to handle the role served by CollectionType. Andrea and I came up with a proposal that not only serves that purpose but also allows a level of customization we have so far not supported but which has been asked for a few

[hibernate-dev] "rebranding" the Hibernate Search "ram" directory

2017-05-18 Thread Sanne Grinovero
As anyone who's bothered to read the manual knows, the "ram" directory should really only be used for unit tests. The other implementations, while typically disk based, are also faster (memory mapped files) and more efficient (better locking design) so there's really no reason to use it, not even p

Re: [hibernate-dev] org.hibernate.event.spi Listener changes for 6 ?

2017-05-18 Thread Gunnar Morling
2017-05-17 2:01 GMT+02:00 Steve Ebersole : > On Tue, May 16, 2017 at 11:20 AM Sanne Grinovero > wrote: > >> Since 6 is coming I'd like to suggest two trivial changes for the >> listeners: >> >> # Serializable >> >> I assume we can drop the "extend Serializable" from all these interfaces ? >> >> >