Like many applications, our's never deletes anything from the database. Instead, our schema has deleted flags. Here's a simplified version:
Person
--------
Id
Deleted
Gender

Name
------
Id
Person_Id
Deleted
Full_Name

I implemented Hibernate Search and it works great... almost. Problem is how do I search for people when some of their names may have been deleted? I don't want searches on deleted names to bring up the person, unless specifically asked for.

For example, suppose I have a person with 2 names, one of which was deleted:
Billy Goat (deleted flag is set to true)
Fred Lion

a search of:
names.full_name:billy
should NOT bring up the person, because the Name entity for Billy Goat has its Deleted flag set to true.

a search of:
names.full_name:fred
should bring up the person

The problem is Hibernate Search stores in lucene names.deleted: true false. So the Deleted flag seems to make no sense to store in lucene unless you are specifically searching names rather than people. So the following search:
a search of:
+names.full_name:billy +names.deleted:false
doesn't really help as it will STILL bring up the person because ONE of the person's names has a deleted flag of false.

Is there a way to write the query like this?
+names.full_name:billy +names.deleted:false{in the same position as names.full_name:billy was found in}

That would be a nice solution. Otherwise it also sucks to store names.deleted: true false for all people unnecessarily (I still want the deleted flag stored for specific searches on names rather than people).

One solution is to just not write the names with deleted=true into the index when indexing people. I'd lose the ability for people to search deleted names (if they wanted to), so it's suboptimal but I can deal with that. I guess I could add another lucene field called names.full_name_deleted and store the name entities there that are deleted. How would I implement this with Hibernate Search? I'd still want the Deleted flag when search Name entities rather than Person entities BY name.

This must be an extremely common situation... what's the best practice here?

Hi,

Unfortunately that's not possible.

What I would to is to define a custom classbridge on the Name entity, and have it index the Full_Name property in a deleted_name field, or in a name field according to the Deleted flag.
This way you can do queries on existing names using the name field only, or enable also deleted_name field when it's ok to return them too; this would work both on queries targeting Name entities and/or Person entities.

Thank you for your response. hmmm... the only issue I can see with your recommendation (which is the second way I suggested above right?) is that it will dramatically complicate my schema. I gave a very simple example of a person and their names. But really I have a TON of these situations nesting many levels deep. I'm fully aware of the performance implications of that, but these are necessary. Even with the Name entity, in our real schema there are going to be 28 fields I need to have 2 versions of (deleted and not deleted).

So as I understand an @ClassBridge simply adds an extra field to the Lucene document for that entity. That means I'll remove all the Hibernate Search annotations on the fields for that entity and create that many @ClassBridge's times 2 (one for deleted and one for non-deleted). If there are 20 fields, I'll do something like:

Suddenly Hibernate Search is starting to seem a lot less useful :(. Am I understanding your suggestion correctly?

No you implement a single @ClassBridge and this will add as many fields as it wants, it's really having full access to the Document being built.
About the usefulness, this means you can plug a cleanly designed transformer for a specific entity: right very similar as what you would do without Search, but you still have the nice index management and event listeners, and it integrates nicely with other class mappings. The framework doesn't prevent you from having low-level access to Lucene.

Ok, I see now an @ClassBridge implementation implements FieldBridge which can add multiple lucene fields.

Is it no longer possible to do projections if I take this ClassBridge approach?

support for automatic de-bridging back to an entity was just committed some days ago, you're welcome to try it out: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372 and send feedback.

As long as you Store them you can always get the String back; so to retrieve each field by name you don't need to go using bleeding edge versions, the patch above is meant to return the rehidratated entity using the same type; Usually projection users don't need the full type but just some selected strings.
Just remember that since you're using low-level apis it's now up to you to properly use STORE on the field options.

Also keep in mind that storing all fields is costly for the index size and consequentially the search performance, and not always the fastest approach to show the results; i.e. it makes sense mostly when you want to show a subset of fields.

Sanne, you've been incredibly helpful on this and other posts, thanks! If I may make a feature suggestion because I believe my situation is a very common one, add a parameter to @Field called condition which takes the name of a boolean field in the same class. If condition is true, add field, otherwise skip it...

that's a reasonable request, but I'm unsure how many usecases it would help.
I'm sending an email to the developer list, feel free to join and defend you request :P, or see if we can find an alternative solution.

The hibernate-dev list: https://www.hibernate.org/20.html#A3

Wow, you sent me a link to the overall hibernate developer list... I thought, "oh man, I have to filter through all hibernate projects to find hibernate search related messages..." But a quick peak at the recent archives indicates it's mostly Hibernate Search discussion. Is Hibernate Search the only actively developed Hibernate project? Or is that a coincidence I happened to see only Hibernate Search discussions?

The other Hibernate projects tend to like IRC better for team communication.