Good question.
return; is what is expected (see HSEARCH-257).
The scenario you are describing (delete + add in the same transaction)
cannot happen in Hibernate unless you use assigned ids and don't have
any kind of association in your object. Even in this case you are
cheating the system. Allowing delete + add kinda reopens HSEARCH-257.
Next time use the forum, it's easier for everyone. And of course, if
you need "ASAP" answers, we have a for pay support. Hibernate Search
in part of our supported platform.
On Mar 23, 2009, at 09:00, Yan Falken wrote:
Hi,
I have the following problem with indexing in transaction with
hibernate
search: in case the transaction is opened and I want to perform
multiple
work types - only one type is actually performed after the commit
and the others are
ignored; example:
TransactionManager tm = new DummyTransactionManager();
tm.begin();
SEntity se1 = new SEntity(10, "first", "second", true);
Work delete = new Work(se1, "100", WorkType.DELETE);
Work add = new Work(se1, "100", WorkType.ADD);
Ctx ctx = new Ctx(tm.getTransaction());
searchFactory.getWorker().performWork(delete, ctx);
searchFactory.getWorker().performWork(add, ctx);
tm.commit();
only DELETE is performed - ADD is ignored
log:
2009-03-23 13:45:02,195 TRACE main|
MaskedProperty| found a match for key:
[hibernate.search.default.indexBase] value: /tmp/c1idx
2009-03-23 13:45:02,195 TRACE main|
MaskedProperty| found a match for key: [default.indexBase] value: /
tmp/c1idx
2009-03-23 13:45:02,341 DEBUG main|
BuilderIndexedEntity| Field selection in projections is set to false
for entity problems.SEntity.
2009-03-23 13:45:02,502 DEBUG pool-1-thread-1|
PerDPQueueProcessor| Skipping usage of an IndexWriter for updates
2009-03-23 13:45:02,503 TRACE pool-1-thread-1|
PerDPQueueProcessor| Locking Workspace (or waiting to...)
2009-03-23 13:45:02,503 TRACE pool-1-thread-1|
PerDPQueueProcessor| Workspace lock aquired.
// opened
2009-03-23 13:45:02,503 DEBUG pool-1-thread-1|
PerDPQueueProcessor| Opening an IndexReader for update
2009-03-23 13:45:02,503 TRACE pool-1-thread-1|
Workspace| IndexReader opened
// only remove
2009-03-23 13:45:02,503 TRACE pool-1-thread-1|
eleteExtWorkDelegate| Removing class problems.SEntity#100 by id
using an IndexReader.
2009-03-23 13:45:02,539 TRACE pool-1-thread-1|
Workspace| IndexReader closed
2009-03-23 13:45:02,539 TRACE pool-1-thread-1|
PerDPQueueProcessor| Unlocking Workspace
I digged into the code a little bit and there is class method:
org
.hibernate
.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which
is in it's beginning iterating the existing queue to avoid
unecessary duplicated works
if ( workType == WorkType.DELETE ) { //TODO add PURGE?
//DELETE should have precedence over any update before (HSEARCH-257)
//if an Add work is here, remove it
//if an other delete is here remember but still search for Add
if ( luceneWork instanceof AddLuceneWork ) {
toDelete.add( luceneWork );
}
else if ( luceneWork instanceof DeleteLuceneWork ) {
duplicateDelete = true;
}
}
else {
//we can safely say we are out, the other work is an ADD
return;
}
I believe that return should be changed to continue. I did several
tests and after the change it can handle ADD/DELETE works in one
queue.
Could you confirm this and tell me in case it's correct how fix
should be raised? Please ignore this email if its design limitation
and the multiple WTs cannot be fixed easily.
Thanks
YF
_______________________________________________
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
