Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Avoid unnecessary index content
PostPosted: Thu Feb 02, 2012 9:11 am 
Pro
Pro

Joined: Wed Nov 05, 2003 7:22 pm
Posts: 208
Sometimes you need to store stuff in the index for one purpose but as a result of embedded relations this may oversize another index.

Let's say we have a user
Code:
User
   Address
      City
          Neighbourhood
          Region
          Country



Now for purposes of loading neighbourhoods quickly, we store these in the index directly
However, when we store a User, we're not really interested in neighbourhoods, just city, country and region ids.
If we use depth = 2, we are not getting the Region, And if we use depth = 3, we're getting the unwanted Neighbourhoods

Because indexedEmbedded doesn't allow us to exclude relations, when we store a user with a city such as New York, his index record will have all of New York's neighbourhoods. You can see how that would grow the index very quickly.

What is the best way to avoid this kind of behaviour?
It seems to me that a classbridge for this would be an inelegant solution. You would have to do quite a bit of manual coding, checking for nulls etc. It also probably doesn't benefit from all the smart dirty checking that HSearch has, leading to more indexing overhead.

It would really be nice to have a more sophisticated approach than depth to specify what to index. I would love to have an additional tag that allows me to specify the fields to index in an embedded relation.

Marc


Top
 Profile  
 
 Post subject: Re: Avoid unnecessary index content
PostPosted: Thu Feb 02, 2012 4:12 pm 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2296
Location: Third rock from the Sun
That's correct, we have better ideas, but would love to hear your opinion too, as we're argumenting on how it should be done exactly:
https://github.com/hibernate/hibernate-search/pull/156

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Avoid unnecessary index content
PostPosted: Sat Feb 04, 2012 12:51 pm 
Pro
Pro

Joined: Wed Nov 05, 2003 7:22 pm
Posts: 208
It's a very interesting discussion and it looks like this would solve my use case.

I also think that there may be differences in the paths to index depending on the root Indexed entity.
Say if
we have
Code:
User
   Address
      City
         Neighbourhood
   OtherRelevantStuff
       ChildStuff


could be different than
Code:
Classiffied
    Address
       City
          Neighbourhood
   OtherRelevantStuff
       ChildStuff


Your solution allows to this to be resolved. One thing I can see is that you probably get the situation that in order to avoid some unwanted relations you have to specify a very low depth and add a lot of manual index fields at the root Indexed Entity.

But in the end that is a small price to pay to have the option. But it does raise the idea of having a reverse selection. In stead of "additionalPaths", also have the option "excludePaths". That may in many cases make a lot more sense.

I also wonder how this would work in classbridge scenario's?

My two cents.

Marc


Top
 Profile  
 
 Post subject: Re: Avoid unnecessary index content
PostPosted: Wed Feb 22, 2012 12:30 pm 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2296
Location: Third rock from the Sun
For the sake of others having the same problem, this was solved: http://in.relation.to/Bloggers/NewPaths ... KnowBetter

Thanks Marc for helping on this!

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 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.