[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Complex EMF Query for a "Simple Query"
Hi, Nirmal,

See some more comments in-line.

HTH,

Christian


On Fri, 2009-05-08 at 17:55 +0200, Nirmal Sasidharan wrote: 
Hello Christian,

Thanks a lot.

I managed to reduce some of my condition objects based on your input.
The code now looks like this (and as you said - simple)

EObjectCondition authorCondition = new EObjectCondition() {
	@Override
	public boolean isSatisfied(EObject object) {
		//Removed reflection for simplicity
		if (object instanceof Writer)
			if (((Writer) object).getBooks().size() > 10)
				return true;

		return false;
	}
};

SELECT select = new SELECT(new FROM(selectedEObjects), new WHERE(
		authorCondition));

Hmmm ... By implementing the entire query in one custom condition, you're basically doing the following in a more complicated framework than is necessary:

Collection<Writer> writers = new java.util.ArrayList<Writert>();
for (TreeIterator<EObject> iter = ECoreUtil.getAllContents(selectedEObjects); iter.hasNext();) {
    EObject next = iter.next();
    if ((object instanceof Writer) && (((Writer) object).getBooks().size() > 10)) {
        writers.add((Writer) next);
    }
}

The reason to use the Query API is to generalize the structure of a query and to separate its parts into reusable/recombinable components.  An EObjectReferenceCondition that does counting of the values can be re-used for any reference.

I didn't extend EObjectReferenceValueCondition as my check was not on an 
EReference of the context, but a computation on my contextual object 
itself (size of Elist containing books).

Well, then extending EObjectStructuralFeatureCondition would generalize the count-function to any feature, whether attribute or reference.  The EObject{Attribute,Reference}ValueCondition classes aren't so useful in this context because they iterate over the feature values, applying conditions individually to each.  Their ancestor classes are better suited to working with the collection value as a whole.

Although, as I mentioned before, this class could be enhanced within the Query framework to support aggregation functions in addition to the exists and forAll quantifier logic.  Basically, a new ConditionPolicy.

I have  different question now about EMF model query solutions 
available. I will post it as a separate thread.

Thanks
Nirmal

-----8<-----