topic Re: real-time search for property value in Alfresco Archive

real-time search for property value

rkerckhoffs — Mon, 23 Jul 2012 10:43:52 GMT

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 node

Re: real-time search for property value

afaust — Tue, 24 Jul 2012 14:33:41 GMT

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

Re: real-time search for property value

andy — Wed, 01 Aug 2012 19:03:42 GMT

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

Re: real-time search for property value

jamen — Fri, 16 Nov 2012 11:49:04 GMT

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?