-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Is there a way to do this?
PostPosted: Wed Dec 31, 2008 2:24 pm 
Regular
Regular

Joined: Fri Oct 05, 2007 3:22 am
Posts: 69
I want to derive search specific entities for my model but yet have incremental updates applied to the original.

I'm not sure if this really even possible but the problem is with the indexing, it is taking a ridiculous amount of time since everything is lazily loaded.

I have addressed this problem initially by using batch and subselect however, although this greatly improves indexing it kills performance in other parts of the application.

I have tried usng HQL to do eager fetching but since we use lists in many places several fetch joins need to be done instead of being able to be done in one shot. This doesn't appear to have helped.

I understand there is no equivalent of batch or subselect that can be overridden or applied via HQL so that leaves me with only join fetch option which would result in refactoring the collections to use Sets instead of Lists

So that being said I'm looking for alternatives that would allow for batch and subselect which is why I was thinking about search specific entities. Another problem is that I have no control over the schema and cannot make changes.

Introducing search specific entities will break incremental updates since updates are being applied to other entities which would not be indexed.

I don't consider having to mirror all entities of search interest with other entities and have them updated via entity callback methods on the original target something of interest.

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 31, 2008 3:25 pm 
Regular
Regular

Joined: Fri Oct 05, 2007 3:22 am
Posts: 69
One more thing I have just noticed.

I have the indexing taking place inside the same transaction and as an experiment I use HQL to select the entity using join fetch on the lazy collections prior to indexing.

The call to the FullTextEntityManager index looks as if the lazy collections which were initialized previously are being read from the db again??

How can this be if the entity that is being passed to index has just been retrieved with HQL and the collections fetched?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 05, 2009 8:59 am 
Hibernate Team
Hibernate Team

Joined: Thu Apr 05, 2007 5:52 am
Posts: 1689
Location: Sweden
Hi,

it might help if you post your entity code and some log output.
Are you sure that the loading of collections is slowing indexing down? There are many parameters which influence the indexing speed, some are Hibernate specific and some are Lucene specific. I recommend you refer to the indexing sections in the online documentation. There is also a section describing how to batch index in a most efficient way.

Regarding the re-fetching of collections - if all relations for the entity to be indexed are already resolved there should be no additional db access. I think it would help to see your code and what queries you are trying to run.

--Hardy


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 05, 2009 6:10 pm 
Regular
Regular

Joined: Fri Oct 05, 2007 3:22 am
Posts: 69
My batch indexing is based on section 9.1.3 from the Hibernate Search Action book. I need to investigate further.

Thanks


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.