Hi all,
After some struggle, I'm now wondering if I shouldn't even not use Hibernate Search for my use case.
Here it is: * Data to index is a reference database that is almost never modified (say, once a year, and we could provide the corresponding index generated once) * The tables are not correctly "relational", and so relationships are mostly not mapped (say, only using part of the pk to reference another table in a fk and so on)
My data model is roughly as follows: /¯\ TreeLevel _ _| | *Master* / Note / NoteType
And what I'm looking for will always be one or many Master instances, according to some fields located in one of those classes (tables) above. For the TreeLevel one, it's even a bit more complicated: it's a reflexive structure (as are tree stores most of the time). And I must create the index to be able to type 1.1 (which would be the TreeLevel 1, having a parent TreeLevel called 1).
So my guess is that I only need one type of Lucene Document with many fields. And it might be simpler in my specific case to use only and directly Lucene. Creating the fields I need to be able to query it, and then handle myself loading the only class instances I'll have to load.
What do you think?
Thanks a lot. PS : please note I'm not saying at all HSearch isn't useful. I'm just wondering if my use case is one where HSearch really adds value.
_________________ Baptiste
PS : please don't forget to give credits below if you found this answer useful :)
|