real-time search for property value

[rkerckhoffs]

For a project of ours we extended the metamodel with a property which adds a md5-hash to each documentNode to see whether the attached file is unique.
I've created a OnContentUpdatePolicy behaviour that executes the needed code.
In that code amongst others I made a lucenequery that searches for nodes with the same propertyvalue as the current node. This routine is working nice. However when using SOLR or doing bulk imports I am facing issues because the index is not completely updated by the time a new node is inserted.
I have tried to avoid accessing the DB itself until now, but it seems there is no other way into doing the search with 100% coverage.

My question are:
- Should I go into accessing the DB itself using the DAO-interface or is there an alternate way into getting the results?
- Is there somewhere a sample project which is doing the same thing?

[afaust]

Hello,

your main problem with DB access will be that there is currently no existing functionality to query all nodes of the repository or a single store by the value of a property. So you would have to implement your own DAO for this. This can be very simple if you can re-use / adapt an already existing query (by this I mean copy & adapt it in your own MyBatis DAO context). I am not aware of any existing samples or documentation since interacting directly with the DB is a rather low-level aspect and should not be encouraged except for the rarest of cases that absolutely can't go without - after all, if done improperly, this may create a hell of a support issue.

I am planning to write up a blog series on custom DAO next chance I have a bit more time on my hands. For a current project I provided a custom CannedQuery and in the past added some custom DAOs for arbitrary data (e.g. in the context of ALF-10838).

Regards
Axel

[andy]

Hi

Properties are in general not easy to query.
You could use the attribute service or create secondary child associations from some check folder with the association named after the checksum.
(The unique name constraint should throw out duplicates)

Andy

[jamen]

We are also looking to do the same thing with querying properties (directly from the database).  Based on this feedback, we may be able to do something different, and heirarchically categorise the items of interest using the AttributeService.  In our case we are interested in a number of NodeRefs, so we could place the node references into a different path as described in the AttributeService interface.

The only concern I have around this is long term performance.  If we were to maintain nodes of interest for a queuing implementation into the following heirarchies

/queueCategory/pending
/queueCategory/succeeded
/queueCategory/failed

1. If we're constantly clearing values for the  pending, succeeded and failed keys are we likely to be safe from performance issues?
2. Is it expected that data lingers in the AttributeService permanently based on a key mapping?