AnsweredAssumed Answered

Best approach to index external text labels

Question asked by iblanco on Apr 27, 2010

I've developed a custom constraint list that takes values and labels from a database. I've also developed a custom component for the Alfresco Explorer web client UI that is able to show the label while maintaining and persisting the value in the node.

This allows me to, for example, persist client codes as a property in a custom type while showing the client's name instead of the code in the web user interface.
The obvious problem is that what is indexed in Lucene is the client's code and not the name, so I can't search the nodes related to the client.

I've thought of various approaches to this problem, But I'm not sure which one is best or even if some of them are possible, some insight about them would be much appreciated:

1) Create a custom indexer that will be used instead of the standard one, so that whenever my custom node's property is indexed the label is returned instead of the value (like in the web client UI).

2) Have a "ghost" property for my custom value that holds the label itself in the node.

3) Have an aspect (extraSearchCriteria aspect) with a multivalued text field and set a behaviour for my property that updates this values

The number 1 seems the most interesting to me, as it will address directly the indexing issues. If my client's name changes in the external database the change won't be propagated until reindexing is forced but that is something that will most probably happen also with the other approaches and solving it would be just a matter or relaunching the indexing, which sound like a quite reasonable thing to do when your searchers are not working as expected.

In some forum topics they talk about replacing all the search engine but I can't find any reasonable reference about changin only the indexing behaviour, is it possible at all?

The number 2 approach seems quite simple but implies creating one "ghost property" for each "real property". If my client's name changes in the database I would have to force the update of all the nodes that have this property (probably not more complicated that reindexing all the repository but not so natural IMHO).

The number 3 is basically number 2 but maybe I could represent all extra search data in an aspect and prepare a more generic aspect and behaviour combination that handles all the required data extraction. The aspect would need to register which properties of the node should receive this "special" treatment and register their label "value" to his "generic ghost field" in the "onUpdate" or "onCreate" event of the node.

I think I'll go for option 3, but some insight on the matter from someone more experienced where be apreciated. Thanks.