[CDO] Query & Lucene [message #997327] |
Sat, 05 January 2013 20:36  |
Eclipse User |
|
|
|
Required: Indexing attributes of the object based on the annotations in the model.
How it can be implemented?
|
|
|
|
|
|
|
Re: [CDO] Query & Lucene [message #998120 is a reply to message #997970] |
Wed, 09 January 2013 07:08   |
Eclipse User |
|
|
|
Hi Eike,
Is this just an idea you have now, thinking out loud, or has it been done like this before? If so, can we get our hands on the code?
I looked at Lucene, it looks pretty much geard towards indexing text, but with EMF models it doesn't seem to have value. (Ok, I didn't dive deep into it, so perhaps I am talking bullocks).
I ended, building an index, which simply listens for invalidations and available server side only. What I needed to index is feature paths.
So i.e. Path 1: Object1.featureX -> Object2.featureY -> Object3.featureY , and simply serialized it as a String and put in a Hashmap with the string as the Key and the CDOID of the last object in the path as the value. A query does a text lookup on the String. Would Lucene add some value to this concept?
Cheers Christophe
[Updated on: Wed, 09 January 2013 07:08] by Moderator
|
|
|
Re: [CDO] Query & Lucene [message #998131 is a reply to message #998120] |
Wed, 09 January 2013 07:24   |
Eclipse User |
|
|
|
Am 09.01.2013 13:08, schrieb Christophe Bouhier:
> Hi Eike,
> Is this jus an idea you have now, thinking out loud, or has it been done like this before? If so, can we get our hands
> on the code?
I haven't done it, nor do I know that someone else has done it. But I've thought a couple times about it ;-)
> I looked at Lucene, it looks pretty much geard towards indexing text, but with EMF models it doesn't seem to have value.
Well there are EDataTypes that do provide text, e.g., EString. I could well imagine model annotations that specify
extraction rules or configure extractor instances per package, class, feature or data type.
> (Ok, I didn't dive deep into it, so perhaps I am talking bullocks).
> I ended, building an index, which simply listens for invalidations and available server side only.
Yes.
> What I needed to index is feature paths.
I'd call those ESettings ;-)
> So i.e. Path 1: Object1.featureX -> Object2.featureY -> Object3.featureY , and simply serialized it as a String and
> put in a Hashmap with the string as the Key and the CDOID of the last object in the path as the value. A query does a
> text lookup on the String. Would Lucene add some value to this concept?
Certainly!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
Re: [CDO] Query & Lucene [message #1000538 is a reply to message #1000254] |
Mon, 14 January 2013 19:29  |
Eclipse User |
|
|
|
Ok! Only CDO API...
Context: CDOCommitInfoHandler#handleCommitInfo(CDOCommitInfo)
CDOCommitInfo have getNewObjects which cast to InternalCDORevision
CDOCommitInfo have getChangedObjects without capabilities cast to InternalCDORevision
My spherical vacuum problem case need only "ChangedObjects" without FeatureDeltas
the similarity InternalCDORevision.getValue(feature)
Thanks!
[Updated on: Mon, 14 January 2013 19:43] by Moderator
|
|
|
Powered by
FUDForum. Page generated in 0.25435 seconds