samd (24) [Avatar] Offline
#1
Hi,

I recently purchased the book and I'm encountering an issue that should be very basic and supported by Hibernate Search. In the following case if I try to index I only pickup X and if I comment out X I will pickup Y. I need both X and Y not just X. This is with your 3.0.1 release.

This is really a show stopper and if doesn't work I'm dead in the water and will need to look at alternatives.

Here are the two annotated methods with real names replaced by X and Y

@Embedded
@ManyToOne( fetch = FetchType.LAZY )
@JoinColumns( { @JoinColumn( nullable = false, name = "X", referencedColumnName = "X" ),
@JoinColumn( nullable = false, name = "X", referencedColumnName = "X" ) } )
@NotNull
@IndexedEmbedded( depth = 999 )
public X getX()
{
return this.x;
}

@OneToMany( cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "Y" )
@IndexedEmbedded( depth = 999 )
public Set<Y> getY()
{
return this.Y;
}
emmanuel.bernard (101) [Avatar] Offline
#2
Re: Only one @IndexedEmbedded collection picked up in an entity.
This is known to work (there are unit tests in the test suite AFAIR)
Can you minimize your problem in a test case and post it to JIRA so that we could have a look.
http://opensource.atlassian.com/projects/hibernate/secure/Dashboard.jspa
emmanuel.bernard (101) [Avatar] Offline
#3
Re: Only one @IndexedEmbedded collection picked up in an entity.
though there was a bug in 3.0.0 in depth computation http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-140
samd (24) [Avatar] Offline
#4
Re: Only one @IndexedEmbedded collection picked up in an entity.
Thanks Emmanuel. I have opened up a JIRA for this. I have upgraded to 3.0.1 and indeed the depth issue has been resolved although my other problem remains.
samd (24) [Avatar] Offline
#5
Re: Only one @IndexedEmbedded collection picked up in an entity.
Emmanuel, I have updated http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-233

The problem is in BatchedQueueingProcessor.processWorkByLayer.

As I mentioned in the original comment for this issue:

"One side note that might be of interest is indexing of Zones results in referencing some entities which don't exist that I'm catching due to the data not being in sync."

I was catching this in our application code but this was not enough. The exception in the processWorkByLayer was causing the thread to die in the first processWorkByLayer called in prepareWorks

processWorkByLayer( queue, initialSize, luceneQueue, Layer.FIRST );
processWorkByLayer( queue, initialSize, luceneQueue, Layer.SECOND );
workQueue.setSealedQueue( luceneQueue );

As a result the workQueue was not being updated with the collection that was missing from the index or so it appears.

Perhaps not trapping exceptions here is intentional but an EntityNotFoundException is common enough so that you might consider it.

Thanks