Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emft-dev] EMF Query projects

I will also mention that I'm interested in an xtext based query language to use with MongoEMF (https://github.com/BryanHunt/mongo-emf/wiki) but haven't had the time to invest in making that happen.

Bryan

On Oct 29, 2012, at 11:37 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:

I saw a demo of this at EclipseCon Europe:
http://www.eclipse.org/proposals/modeling.emf.incquery/
It's the coolest thing I've seen in quite some time.  It's very focused on live in-memory models, so that might not be appropriate for many use cases.  But I'm particularly interested in providing a mechanism for Xcore to delegate to such external queries because it would be an ideal way to define derived features that notify just like a normal feature when the derived value changes (all without needing to manage the necessary adapters yourself).


On 29/10/2012 6:52 PM, Ed Willink wrote:
Hi

Readability: a surprising number of OCL constructs appear in rather similar form in Xbase, so I tend to regard the readability argument as one used only to justify a prejudice. OCL is a good compromise between Java-like notations and the genuinely challenging formal notations such as Z. [You ought to use an abacus because that's the only approach that really lets you visualize your numbers.]

Caching: The OCL Impact Analyzer supports caching of threshold results so that a re-evaluation can be performed in constant time even for huge models. EMF-IncQuery has larger more efficient caches for similar pattern-based goals. OCL and EMF-IncQuery are likely to converge as different execution aspects. See our EclipseCon prersentation (http://www.eclipse.org/modeling/mdt/ocl/docs/publications/EclipseConEurope2012/FastQueries.pdf) where SQL-like approaches are an order of magnitude worse than in-memory EMF approaches; the various EMF-Query projects were too bad to even put on the technology comparison in slide 5.

What form of caching do you require? OCL is under active development so may be something can be added. Currently OCL has custom meta-model representations to support fast dynamic dispatch and transitive reflection. Custom model representations may be interesting too, but only where it can be established that the costs/complexities of loading/converting to/from a restrictive EObject are justified. For closed domains such as model transformations this can be useful; perhaps it may suit your use cases too.

    Regards

        Ed Willink

On 29/10/2012 16:24, Miles Parker wrote:
Yes, that's one possibility I'm thinking of, but would you suggest using that w/in EMF Query or just stand-alone? OCL would be a good way to go for the formal representation, though it is arguably not as human readable (for non-CS majors, anyway) as some potential XPath / *QL approaches. (I realize the inherent limitations of those approaches, I'm just thinking in terms of support for basic boolean constructs, simple containment, etc..) I like the idea of going to Java code, though right now my solution is already effectively in Java code but I want a more generic representation and good search time performance, and right now I'm stuck w/ brain-dead O(n) with perhaps a bit of DIY caching. Does the OCL implementation (or any other extant tools) support any kind of indexing and/or caching?

Too bad to hear about Query2. As Ed suggests, I think there were some neat ideas in there.


On 2012-10-29, at 2:32 AM, Ed Willink<ed@xxxxxxxxxxxxx>  wrote:

Hi Miles

You can of course use OCL as a query language. Juno introduces an experimental OCL to Java code generator. I'm actively improving this so that the UML 2.5 OCL (and all of OCL's own) constraints can be used in auto-generated form.

      Regards

         Ed Willink

On 29/10/2012 07:40, Saurav Sarkar wrote:
Hi Miles,

Unfortunately not much of an activity is there in EMF Query2.
We have only two committers and both of us are currently engaged in some other commitments.
Hence we are not able to devote time and to do enough justification to the project.

In fact currently we are contemplating to go ahead for termination and initiating talks with other stakeholders.
Let me know your suggestions/comments or if any other points you have.

In fact i was planning to announce the same over the forums and mailing list, but since this mail came first this is the update i have.

The same question goes to the whole community to provide their suggestions.

cheers,
Saurav

On Mon, Oct 29, 2012 at 11:05 AM, Ed Merks<ed.merks@xxxxxxxxx>  wrote:
Miles,

The problem is that both teams appear to be dysfunctional.  The older IBM-managed project is definitely not being actively developed, and, in my opinion, is not likely to address anyone's needs.  The newer SAP-managed project seems more active, and more interesting, but the team appears to be out of touch with the community, as you can see from the lack of response to your email. Query 2 missed the train for Juno and I've seen no sign that they'll give Kepler any thought until it's too late for that as well.



On 26/10/2012 11:10 PM, Miles Parker wrote:
Hi all,

I'm looking for some insight into status of EMF Query projects. Specifically, which are under active development? Judging by the name and versioning, it would seem to be Query 2, but OTOH, I need to consume from train and it doesn't look like it made it into Juno? Are there plans for Kepler?

cheers,

Miles

_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev

_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev



_______________________________________________
emft-dev mailing list

emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / Virus Database: 2617/5859 - Release Date: 10/28/12

_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev
_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / Virus Database: 2617/5859 - Release Date: 10/28/12



_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev

_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev


Back to the top