[CDO] Query & Lucene [message #997327] |
Sun, 06 January 2013 01:36 |
Mixa Alekseev Messages: 10 Registered: February 2011 |
Junior Member |
|
|
Required: Indexing attributes of the object based on the annotations in the model.
How it can be implemented?
Sorry for my bad English.
|
|
|
|
|
|
|
Re: [CDO] Query & Lucene [message #998120 is a reply to message #997970] |
Wed, 09 January 2013 12:08 |
Christophe Bouhier Messages: 937 Registered: July 2009 |
Senior Member |
|
|
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 12:08] Report message to a moderator
|
|
|
Re: [CDO] Query & Lucene [message #998131 is a reply to message #998120] |
Wed, 09 January 2013 12:24 |
|
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
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] |
Tue, 15 January 2013 00:29 |
Mixa Alekseev Messages: 10 Registered: February 2011 |
Junior Member |
|
|
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!
Sorry for my bad English.
[Updated on: Tue, 15 January 2013 00:43] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.05693 seconds