There is an experimental feature in Hibernate Search which is as well known and as well documented as an easter egg: org.hibernate.search.sandbox.standalone.FullTextManager allows to use Hibernate Search in "standalone" mode, i.e. without a database and storing all data in the Lucene index only. This doesn't even have tests, but hasn't harmed any kitten so far. However now while I'm looking at doing some refactorings in preparation of Lucene 4, this looks like something that will need a complete rewrite, and is adding some resistance already by depending on deprecated methods which I'd rather remove asap. So I'm proposing to delete it, for the time being with no replacement. If there is interest we'd need to rewrite it anyway, but I'd prefer doing that eventually after the migration. Are we all ok with this? Cheers, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

HI Hardy, Just want to know is JDBC batch updates not supported with HQL queries any ways it can be achieved Regards, Sujit On Sun, May 19, 2013 at 12:57 PM, Hardy Ferentschik <hardy(a)hibernate.org&gt;wrote: > +1 > > I was not even aware of it. Was it one of your experiments? > > > > On 18 May 2013, at 23:59, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > > There is an experimental feature in Hibernate Search which is as well > > known and as well documented as an easter egg: > > > > org.hibernate.search.sandbox.standalone.FullTextManager > > > > allows to use Hibernate Search in "standalone" mode, i.e. without a > > database and storing all data in the Lucene index only. > > > > This doesn't even have tests, but hasn't harmed any kitten so far. > > However now while I'm looking at doing some refactorings in > > preparation of Lucene 4, this looks like something that will need a > > complete rewrite, and is adding some resistance already by depending > > on deprecated methods which I'd rather remove asap. > > > > So I'm proposing to delete it, for the time being with no replacement. > > If there is interest we'd need to rewrite it anyway, but I'd prefer > > doing that eventually after the migration. > > > > Are we all ok with this? > > > > Cheers, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 19 May 2013 08:27, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: > +1 > > I was not even aware of it. Was it one of your experiments? No it was one of Emmanuel's experiments, so I'd like his +1 as well ;-) I don't dislike the concept, maybe this is something that could be reincarnated as an OGM dialect? Or if it was meant to be more Lucene-API centric, maybe it could become a separate module in Search (separate than hibernate-search-engine, so at the same level of hibernate-search-orm) Sanne > > > > On 18 May 2013, at 23:59, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > >> There is an experimental feature in Hibernate Search which is as well >> known and as well documented as an easter egg: >> >> org.hibernate.search.sandbox.standalone.FullTextManager >> >> allows to use Hibernate Search in "standalone" mode, i.e. without a >> database and storing all data in the Lucene index only. >> >> This doesn't even have tests, but hasn't harmed any kitten so far. >> However now while I'm looking at doing some refactorings in >> preparation of Lucene 4, this looks like something that will need a >> complete rewrite, and is adding some resistance already by depending >> on deprecated methods which I'd rather remove asap. >> >> So I'm proposing to delete it, for the time being with no replacement. >> If there is interest we'd need to rewrite it anyway, but I'd prefer >> doing that eventually after the migration. >> >> Are we all ok with this? >> >> Cheers, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev