Hello,
I need to do "manual" indexing. Once a day i'm scheduled to to re-index Orders that changed during this day ("delta").
If I write it from scratch, I need to query for "Orders that were created/changed today".
And if I have "index embedded" I need to query for "Orders that changed, OR any of their Items changed" (or I can put a trigger, so change in Item also marks its parent Order as 'modified').
And maintenance - if Order gets more embedded data ("customer info"), I must remember to fix the query (Orders that changed, or their Items changed, or the Customer info changed). And it's easy for QA to miss if I forgot.
Finally I need the "red tape" of setting up a Timer for the task.

Do hibernate search help here?

Hi,

I have no idea about your Order and Item classes. It is hard to give recommendations if you don't post the code. But generally, yes, you would write a query which retrieves the changed entities (eg via a timestamp) and re-index these.

Any particular reason you don't want to use automatic indexing?

--Hardy

Thank you for the answer.
Sorry for not posting the code: it is 1:M bidirectional relation between Order and Item, and you can search Order by Item name (sorry if this requirement looks weird, we really though it through, but it's a simplified example).

@Indexed @Entity(...) class Order{
@Id @DocumentId private int id;
@Field @Column private String orderName;
@OneToMany(...) @IndexEmbedded private List<Items> items = new ArrayList();
@Column private long modified;
}

@Indexed (...) class Item {
@Id @DocumentId private int id;
@Field @Column private String itemName;
@ManyToOne(...) @ContainedIn private Order parentOrder;
@Column private long modified;
}

To your question - we chose daily reindex because we have good experience with it (from before we migrated to Hibernate search).
Our users do lots of inserts (more than the traditional example of "online store"), and need it to be fast, while we don't care that much about stale data.

The problem is, if you modify a single item, the item is marked as modified, but the parent Order keeps the old timestamp.
So if I reindex Orders, it's not enough to select "Orders that were modified today"... I need "Orders that were modified themselves, or that contain modified items".
I though maybe other people ran into this problem (everyone who does manual reindexing on 1:M relations)... and whether there are utilities or "best practices" for it.

Thank you .

Hi again,

if you want to stick w/ the manual re-indexing approach and only index the changed entities you need to write a query which captures these changes entities. I guess you could just write a Criteria query to select Order instances which have modified items. Note, that due to @ContainedIn you don't have to re-index the Order instance which contains a reference to a changed item. If you re-index the item the corresponding order gets re-indexed as well. But if I understood correctly you also have the case where the order changes w/o any changes in the items.
Maybe just run two queries? Maybe it is also worth evaluating automatic indexing? Provided you don't have any performance issues you are done w/ just changing a few configuration settings (one really). If you get performance problems you might want to investigate the master/slave setup as described in the online documentation.

--Hardy

This is such good news. The "Contained in" really helps me ( I just didn't think about it).
Thank you!!