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
|
