[hibernate-dev] [hibernate-announce] OGM 4.0.0.Beta3 released
http://in.relation.to/Bloggers/HibernateOGM4Beta3IsOut Davide ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Search 4.4.0.Beta1 : now supports dynamic sharding
We released Hibernate Search 4.4.0.Beta1 past Friday night, with a short post about the new cool feature: http://in.relation.to/Bloggers/HibernateSearch440Beta1IndexShardingIsNowDynamic --Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HSEARCH-1270 : indexing (still) happening after Session#clear()
I'm having a half-baked solution for HSEARCH-1270, and it looks like I can't do better than that without waiting for HHH-8577 to be included in ORM [JIRA links at the bottom]. # The problem described by HSEARCH-1270 After the user has enqueued some indexing operations in Hibernate Search's Worker, if he then invokes Session.clear() the queue is not cleared. I realize that clear() might not be as popular as most other methods on Session, still I consider this an annoying limitation: it introduces an inconsistency in the index and the user might not even realize the mistake, and neither do we have an opportunity to warn him. # Partial solution This is working well, and the test passes: https://github.com/Sanne/hibernate-search/compare/HSEARCH-1270?expand=1 #Why it's not complete The test requires to invoke the clear() operation *after* having wrapped the Session in a FullTextSession. In other words, if I'm just using the Session the bug would still manifest. #What now Considering that we can't do better than that - at least without patching ORM with HHH-8577 - would you still merge such a patch? I would propose to merge it, and add a warning in the docs, at least the user has an option to workaround the issue. The downside is that so far, at least Session and FullTextSession behave consistently.. was that a good thing? Another approach to the problem could be to provide an explicit FullTextSession#clearIndexingQueue() I think I'd like that, especially as it can be useful in other situations, for example to avoid triggering any indexing operation for a specific transaction. Also, it would be a good companion for FullTextSession#flushToIndexes() -- Sanne https://hibernate.atlassian.net/browse/HSEARCH-1270 https://hibernate.atlassian.net/browse/HHH-8577 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH-1270 : indexing (still) happening after Session#clear()
To better explain the idea, this is exactly what I have in mind: https://github.com/Sanne/hibernate-search/compare/ba01525c88a5445b5a210043630cd355c1b56aba?expand=1 Sanne On 30 September 2013 22:00, Sanne Grinovero wrote: > I'm having a half-baked solution for HSEARCH-1270, and it looks like I > can't do better than that without waiting for HHH-8577 to be included > in ORM [JIRA links at the bottom]. > > # The problem described by HSEARCH-1270 > After the user has enqueued some indexing operations in Hibernate > Search's Worker, if he then invokes Session.clear() the queue is not > cleared. > > I realize that clear() might not be as popular as most other methods > on Session, still I consider this an annoying limitation: it > introduces an inconsistency in the index and the user might not even > realize the mistake, and neither do we have an opportunity to warn > him. > > # Partial solution > This is working well, and the test passes: > > https://github.com/Sanne/hibernate-search/compare/HSEARCH-1270?expand=1 > > #Why it's not complete > The test requires to invoke the clear() operation *after* having > wrapped the Session in a FullTextSession. > In other words, if I'm just using the Session the bug would still manifest. > > #What now > Considering that we can't do better than that - at least without > patching ORM with HHH-8577 - would you still merge such a patch? > > I would propose to merge it, and add a warning in the docs, at least > the user has an option to workaround the issue. > The downside is that so far, at least Session and FullTextSession > behave consistently.. was that a good thing? > > Another approach to the problem could be to provide an explicit > >FullTextSession#clearIndexingQueue() > > I think I'd like that, especially as it can be useful in other > situations, for example to avoid triggering any indexing operation for > a specific transaction. > Also, it would be a good companion for > >FullTextSession#flushToIndexes() > > -- Sanne > > https://hibernate.atlassian.net/browse/HSEARCH-1270 > https://hibernate.atlassian.net/browse/HHH-8577 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
