Home » Modeling » EMF » [CDO] Importing resources with elements referencing external elements
| [CDO] Importing resources with elements referencing external elements [message #420628] |
Fri, 04 July 2008 12:22  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi!
I'm new to the joyful world of CDO (great job!) and planning to stay in
it for a while :P My project implies dealing with huge models, where we
need our environment to work just with fragments of it, and load
on-demand referenced elements when needed. AFAIK, CDO promises doing
that! :D
After get to deploy the server (I couldn't find anything about it, maybe
some documentation about that would be nice, since it's a critical step
to get into CDO. I wouldn't mind to help with that :P) and trying some
transaction through the "CDO Sessions" view, I found the first issue: I
had to import 3 models (I mean, certain CDO-ready .ecore instances) into
the repository, and one of them was referencing elements of the
remaining two models. When I register that model, these references just
dissappear. Right clicking and using "load resource..." won't work,
since it hasn't been enhanced yet to include the model repository as
source.
Any idea to make some model element reference something contained in
another resource? Am I missing something?
Victor.
Open Canarias.
|
|
|
| Re: [CDO] Importing resources with elements referencing external elements [message #420639 is a reply to message #420628] |
Fri, 04 July 2008 16:17  |
|
Hi Victor,
Coments below...
Víctor Roldán Betancort schrieb:
> Hi!
>
> I'm new to the joyful world of CDO (great job!) and planning to stay
> in it for a while :P
Welcome ;-)
> My project implies dealing with huge models, where we need our
> environment to work just with fragments of it, and load on-demand
> referenced elements when needed. AFAIK, CDO promises doing that! :D
That's right, we think CDO is particularly well-suited for huge models
due to its internal unconnected representation of the loaded model parts.
>
> After get to deploy the server (I couldn't find anything about it,
> maybe some documentation about that would be nice, since it's a
> critical step to get into CDO.
I know that the current learning curve is initially steep and it would
be much easier with better documentation.
http://wiki.eclipse.org/CDO_Server_Configuration is far from complete.
I plan to enhance the JavaDocs and enrich it with lots of code and
config examples asap.
> I wouldn't mind to help with that :P)
That sounds like a cool idea ;-)
Please feel free to add to
http://wiki.eclipse.org/User_Contributed_CDO_Documentation
> and trying some transaction through the "CDO Sessions" view, I found
> the first issue: I had to import 3 models (I mean, certain CDO-ready
> .ecore instances)
I guess you mean M0 models? Due to the ambiguity of the term "model" I
find the terms "package" and "resource" easier, although I'm also often
tempted to say model instead of package or resource ;-(
> into the repository, and one of them was referencing elements of the
> remaining two models. When I register that model, these references
> just dissappear.
Now I'm confused (about the verb "register"): I'd say packages can
*reference* each other, just as resources can. Packages can be
*registered* with the repository (via the client side package registry
of the session) and resources can be *imported* into the repository via
te CDO UI.
What exactly do you mean by "register"?
> Right clicking and using "load resource..." won't work, since it
> hasn't been enhanced yet to include the model repository as source.
Hm, again confusion on my side. What do you mean by "enhanced"?
Also I feel that you might not be using the CDO UI, i.e. the CDOEditor,
because there "Load Resource..." would mean to load a resource that
already exists in the repository into the local view (i.e. the
ResourceSet of the CDOEditor). Before I had the impression that you talk
about "Import Resource..." as available in the CDOSessionsView.
Sorry, I must have a dumb moment ;-(
>
> Any idea to make some model element reference something contained in
> another resource? Am I missing something?
If you populate your model (object graph) step by step through the CDO
UI it's just a matter of having the desired resources in the editor by
either "load resource" or "create resoure". Then all objects are
available for being referenced.
If you try to populate it by *importing* local resources (e.g. xml
documents) into the resource set of the editor there might indeed be an
issue if these local resources have references between them! The current
import operation is not capable of importing referenced resources so
from a CDO point of view these references look like external references
and these are not allowed.
There are two solutions:
1) Enhance the "import resource" operation to import multiple resources
as a whole so that they are "closed" with respect to the contained
object graph. I knew this issue would arise but was unsure how to design
the user workflow since the mapping of local resource *URIs* to
repository resource *paths* is not implicit. Please feel free to file an
enhancement request, but be prepared to participate in the discussion on
how exactly to design this workflow.
2) This existing Bugzilla might be related: 213402: Support
inter-repository references
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
In fact the title of this Bugzilla should be broadened to "Support
external references" since from a repository point of view there won't
be much of a difference between references into other repositories and
references to any other sort of resources. Feel free to change the title
and give a short explanation for the record.
Thinking once more I believe that 2) wouldn't really solve your problem
since it would import external references into your repository that
wouldn't change magically just by importing the referenced resources
into the repository!
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Importing resources with elements referencing external elements [message #420656 is a reply to message #420639] |
Sat, 05 July 2008 22:50 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Eike!
Thanks for your valuable feedback, and excuse me with my bad
explanation. Still, you got my point :)
Some coments below:
>> I wouldn't mind to help with that :P)
> That sounds like a cool idea ;-)
> Please feel free to add to
> http://wiki.eclipse.org/User_Contributed_CDO_Documentation
As soon as I get back from my vacation from Germany I'll
try to send you an html with tutorials on how to deploy and connect to a
derby database and also how to connect CDO to MySQL (what I got so far
in 1 day experimentation).
>> and trying some transaction through the "CDO Sessions" view, I found
>> the first issue: I had to import 3 models (I mean, certain CDO-ready
>> .ecore instances)
> I guess you mean M0 models? Due to the ambiguity of the term "model" I
> find the terms "package" and "resource" easier, although I'm also often
> tempted to say model instead of package or resource ;-(
Well, the MOF piramid is certainly quite ambiguous, since MOF is
reflexive, you could think about it as M2, M3...Mn, so what you refer as
"resource" might be at M1 or M0. Sorry about that, I'll use your naming
convention. From here on Ill supose you refer to packages to, let say
"myExample.ecore" (what I use to call "metamodel") and then to resources
as, for instance, "res1.myexaample" ("model" or "metamodel instance" or...)
>
>> into the repository, and one of them was referencing elements of the
>> remaining two models. When I register that model, these references
>> just dissappear.
> Now I'm confused (about the verb "register"): I'd say packages can
> *reference* each other, just as resources can. Packages can be
> *registered* with the repository (via the client side package registry
> of the session) and resources can be *imported* into the repository via
> te CDO UI.
>
> What exactly do you mean by "register"?
>
Excuse me again, I wrongly used the term "register" when I indeed wanted
to mean "import" :( You are totally right.
>> Right clicking and using "load resource..." won't work, since it
>> hasn't been enhanced yet to include the model repository as source.
> Hm, again confusion on my side. What do you mean by "enhanced"?
> Also I feel that you might not be using the CDO UI, i.e. the CDOEditor,
> because there "Load Resource..." would mean to load a resource that
> already exists in the repository into the local view (i.e. the
> ResourceSet of the CDOEditor). Before I had the impression that you talk
> about "Import Resource..." as available in the CDOSessionsView.
>
> Sorry, I must have a dumb moment ;-(
>
Well in this case I was talking about a different "load resource"
operation than you are referring to. Usually, when Im using Ecore sample
editor, if I want to reference to some element in an external resource,
I use that feature, which pops up a window to choose some resource that
will be loaded into the current editor's (Ecore editor) ResourceSet. I
expected CDOEditor to do the same but also having a new option to load
into that ResourceSet an arbitrary repository, which would allow to
reference elements from it. (thats what I meant with "enhanced"). I
assume CDOSessionView's "load resource" just opens a new CDOEditor with
the corresponding repository loaded into its own ResourceSet (or do all
opened Editors share the same ResourceSet? :-S ). On the other hand, and
if Im not wrong, every time you load a resource at an Ecore sample
editor, that resource is loaded into the same ResourceSet.
The point is that I only have to ways to make reference to an external
resource: first, using "load resource" at Ecore sample editor, and two,
editing XMI.
>>
>> Any idea to make some model element reference something contained in
>> another resource? Am I missing something?
> If you populate your model (object graph) step by step through the CDO
> UI it's just a matter of having the desired resources in the editor by
> either "load resource" or "create resoure". Then all objects are
> available for being referenced.
Does this mean that, if you have several repo's loaded into
CDOSessionView, you can reference from one repo element to another
repo's? (According to bug 213402, I guess you can't, right?)
> If you try to populate it by *importing* local resources (e.g. xml
> documents) into the resource set of the editor there might indeed be an
> issue if these local resources have references between them! The current
> import operation is not capable of importing referenced resources so
> from a CDO point of view these references look like external references
> and these are not allowed.
Yes, I you are right. In reference to this, see next comment.
>
> There are two solutions:
>
> 1) Enhance the "import resource" operation to import multiple resources
> as a whole so that they are "closed" with respect to the contained
> object graph. I knew this issue would arise but was unsure how to design
> the user workflow since the mapping of local resource *URIs* to
> repository resource *paths* is not implicit. Please feel free to file an
> enhancement request, but be prepared to participate in the discussion on
> how exactly to design this workflow.
>
> 2) This existing Bugzilla might be related: 213402: Support
> inter-repository references
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
>
I have thought a little bit about this, and my conclusions are:
1. First of all, in my opinion, inter-repository references might be an
important enhancement. At least for me, this kind of references are a
recurrent situation. Some metamodels (sorry, I mean package :P) might
refer to elements from other packages (for instance, QVT languages use
OCL elements). In reference to this, I might have an idea, but of
course, I talk without to much knowledge about your CDO. I assume you
use CDOID (I guess thats something like XMI:id) to reference to an
element, and I also assume that's used like a primary key. We could add
another column to that table including the name of the repository
containing the element identified by that CDOID. If we leave it empty,
It would mean that the referenced element is local to that repo. If you
set a value, it would mean "hey, go to repo XXX and get element
identified by this CDOID".
Please excuse me if I'm just too out on how CDO actually works.
2. In reference to "resource import workflow" I imagine something like this:
1. User imports a local resource
2. CDO detects that there are external references and offers to
import automatically those into the database. Users might choose a name
for the repo corresponding to that resource. Also user might choose not
to import that resource, leaving the first resource's repo inconsistent
at their own risk (meaning that references to external resources will
just be ignored and set to null/unset).
There are some special situations that should be managed, like recursive
dependencies (resource "a" depends on "b", and viceversa) or transitive
(a depends on b, b on c, c on .....).
> In fact the title of this Bugzilla should be broadened to "Support
> external references" since from a repository point of view there won't
> be much of a difference between references into other repositories and
> references to any other sort of resources. Feel free to change the title
> and give a short explanation for the record.
>
Yeah, this situation could also be feasible, I guess at some point
someone might need to set references in a repo's element to an external
resource, although I can't imagine a practical situation right now.
> Thinking once more I believe that 2) wouldn't really solve your problem
> since it would import external references into your repository that
> wouldn't change magically just by importing the referenced resources
> into the repository!
Yep, It wouldnt, as I explained before.
>
> Cheers
> /Eike
I'll be pleased to help you out with these new requirements (only if you
find them necessary/useful. I do ;) ), but I'll need some time to
understand enough of your project architecture :P
Regards!
Victor.
Open Canarias.
|
|
|
| Re: [CDO] Importing resources with elements referencing external elements [message #420657 is a reply to message #420656] |
Sun, 06 July 2008 05:39 |
|
Victor Roldan Betancort schrieb:
> Hi Eike!
>
> Thanks for your valuable feedback, and excuse me with my bad
> explanation. Still, you got my point :)
Well, it's not that bad ;-)
And sorry for being picky about terminology, it's more to come to a
common understanding (in particular my understanding) than just to teach you
> Some coments below:
>
> >> I wouldn't mind to help with that :P)
> > That sounds like a cool idea ;-)
> > Please feel free to add to
> > http://wiki.eclipse.org/User_Contributed_CDO_Documentation
>
> As soon as I get back from my vacation from Germany I'll
> try to send you an html with tutorials on how to deploy and connect to a
> derby database and also how to connect CDO to MySQL (what I got so far
> in 1 day experimentation).
I'll have to find a tool to convert to wiki format, but cool anyway ;-)
Where in Germany are you?
I'm living in Berlin.
> >> and trying some transaction through the "CDO Sessions" view, I found
> >> the first issue: I had to import 3 models (I mean, certain CDO-ready
> >> .ecore instances)
> > I guess you mean M0 models? Due to the ambiguity of the term "model" I
> > find the terms "package" and "resource" easier, although I'm also often
> > tempted to say model instead of package or resource ;-(
>
> Well, the MOF piramid is certainly quite ambiguous, since MOF is
> reflexive, you could think about it as M2, M3...Mn, so what you refer as
> "resource" might be at M1 or M0. Sorry about that, I'll use your naming
> convention. From here on Ill supose you refer to packages to, let say
> "myExample.ecore" (what I use to call "metamodel") and then to resources
> as, for instance, "res1.myexaample" ("model" or "metamodel instance"
> or...)
Hehe, I saw this MOF discussion coming when I wrote M0 ;-)
Ed might want to re-iterate that the meta prefix can be avoided most of
the times...
> >> into the repository, and one of them was referencing elements of the
> >> remaining two models. When I register that model, these references
> >> just dissappear.
> > Now I'm confused (about the verb "register"): I'd say packages can
> > *reference* each other, just as resources can. Packages can be
> > *registered* with the repository (via the client side package registry
> > of the session) and resources can be *imported* into the repository via
> > te CDO UI.
> >
> > What exactly do you mean by "register"?
> >
>
> Excuse me again, I wrongly used the term "register" when I indeed wanted
> to mean "import" :( You are totally right.
>
> >> Right clicking and using "load resource..." won't work, since it
> >> hasn't been enhanced yet to include the model repository as source.
> > Hm, again confusion on my side. What do you mean by "enhanced"?
> > Also I feel that you might not be using the CDO UI, i.e. the CDOEditor,
> > because there "Load Resource..." would mean to load a resource that
> > already exists in the repository into the local view (i.e. the
> > ResourceSet of the CDOEditor). Before I had the impression that you
> talk
> > about "Import Resource..." as available in the CDOSessionsView.
> >
> > Sorry, I must have a dumb moment ;-(
> >
>
> Well in this case I was talking about a different "load resource"
> operation than you are referring to. Usually, when Im using Ecore sample
> editor, if I want to reference to some element in an external
> resource, I use that feature, which pops up a window to choose some
> resource that
> will be loaded into the current editor's (Ecore editor) ResourceSet. I
> expected CDOEditor to do the same but also having a new option to load
> into that ResourceSet an arbitrary repository, which would allow to
> reference elements from it. (thats what I meant with "enhanced").
I see. In any case you can't import a whole repository which generally
consists of one or several resources. BTW in CDO a resource is "just" a
top level object in the repository. Think of it as a named entry point
into the object graph. In fact CDOResource extends CDOObject which
extends EObject.
> I assume CDOSessionView's "load resource" just opens a new CDOEditor with
> the corresponding repository loaded into its own ResourceSet (or do all
> opened Editors share the same ResourceSet? :-S ).
Yes, all open CDOEditors share the same ResourceSet which is managed by
the CDOView (or CDOTransaction or CDOAudit). For other editor
implementations this might depend.
> On the other hand, and
> if Im not wrong, every time you load a resource at an Ecore sample
> editor, that resource is loaded into the same ResourceSet.
AFAIK all editors that are shipped with or generated by EMF use their
own dedicated ResourceSet until you change that somehow.
Have you already tried the CDOEditor? If you're locked to generated ones
this could be an option and you'd get many features for free like
asynchronous change notification, transactionality feedback, etc...
> The point is that I only have to ways to make reference to an external
> resource: first, using "load resource" at Ecore sample editor, and two,
> editing XMI.
I think the first way is nicer for users.
> >> Any idea to make some model element reference something contained in
> >> another resource? Am I missing something?
> > If you populate your model (object graph) step by step through the CDO
> > UI it's just a matter of having the desired resources in the editor by
> > either "load resource" or "create resoure". Then all objects are
> > available for being referenced.
>
> Does this mean that, if you have several repo's loaded into
> CDOSessionView, you can reference from one repo element to another
> repo's? (According to bug 213402, I guess you can't, right?)
You can open sessions to different repositories which are possibly on
different hosts or even local.
But no, there's no trick to create references from one repository to
anything else outside of this repository.
At least no EReferences. Of course you could prepare your model and
application accordingly to be able to dereference any semantic data.
You could model derived features (EReferences) that turn for example
some String EAttribute into an EReference.
The main challenge here will be (and that's the reason while I postponed
Bugzilla #213402) to separate the full information about the target
object into one part that identifies the object within a ResourceSet
(i.e. resource URI and fragment) and one part that tells how to create
the appropriate ResourceSet. The first part could be stored in the
EAttribute somewhere *within* the repository. But your *application*
needs to provide additional information, for example *how* to open a new
CDOSession, e.g. which connector to use, what package registry to use,
etc...
> > If you try to populate it by *importing* local resources (e.g. xml
> > documents) into the resource set of the editor there might indeed be an
> > issue if these local resources have references between them! The
> current
> > import operation is not capable of importing referenced resources so
> > from a CDO point of view these references look like external references
> > and these are not allowed.
>
> Yes, I you are right. In reference to this, see next comment.
>
> >
> > There are two solutions:
> >
> > 1) Enhance the "import resource" operation to import multiple resources
> > as a whole so that they are "closed" with respect to the contained
> > object graph. I knew this issue would arise but was unsure how to
> design
> > the user workflow since the mapping of local resource *URIs* to
> > repository resource *paths* is not implicit. Please feel free to
> file an
> > enhancement request, but be prepared to participate in the
> discussion on
> > how exactly to design this workflow.
> >
> > 2) This existing Bugzilla might be related: 213402: Support
> > inter-repository references
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
> >
>
> I have thought a little bit about this, and my conclusions are:
>
> 1. First of all, in my opinion, inter-repository references might be an
> important enhancement. At least for me, this kind of references are a
> recurrent situation.
Agreed. While we can investigate and discuss respective solutions
(especially if you're able and willing to contribute) it's important at
this point to recognize that a CDO repository is, as opposed to the
ResourceSet concept of EMF, a "closed world"! For sure this has its own
pros and cons. I only fear that minor changes to this basic assumption
might have a major impact on the current design and implementation. But
let's see...
> Some metamodels (sorry, I mean package :P) might
> refer to elements from other packages (for instance, QVT languages use
> OCL elements).
That's generally not a problem with CDO. A repository can have arbitrary
numbers of packages registered, referencing each other, possibly even in
a circular manner (not that I want to foster this!).
And a repository can contain arbitrary numbers of resources. The objects
in the resources can be mixed of multiple packages and they can refer to
objects in other resources (within the same repository).
> In reference to this, I might have an idea, but of
> course, I talk without to much knowledge about your CDO. I assume you
> use CDOID (I guess thats something like XMI:id) to reference to an
> element, and I also assume that's used like a primary key.
A CDOID is a store-defined, immutable and persistent object identifier.
It's guaranteed to be unique in the scope of the whole repository, i.e.
it does even not change if an object is moved across resources, in
contrast to an XML URI.
Store-defined means that not only the value but also the format (Java
implementation) is dependent of the store implementation.
> We could add another column to that table including the name of the
> repository
> containing the element identified by that CDOID. If we leave it empty,
> It would mean that the referenced element is local to that repo. If
> you set a value, it would mean "hey, go to repo XXX and get element
> identified by this CDOID".
As I said above, the name of the repository would not be enough to
determine *how* to open a session to this respoitory ;-(
That does not mean there's no solution. It's just a challenge to find
appropriate solutions.
We should discuss that in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
> Please excuse me if I'm just too out on how CDO actually works.
>
> 2. In reference to "resource import workflow" I imagine something like
> this:
>
> 1. User imports a local resource
> 2. CDO detects that there are external references and offers to
> import automatically those into the database. Users might choose a name
> for the repo corresponding to that resource. Also user might choose not
> to import that resource, leaving the first resource's repo inconsistent
> at their own risk (meaning that references to external resources will
> just be ignored and set to null/unset).
I'm still a bit suspicious about these repository inconsistencies but
you might be right. If it's at user's explicit choice.
I feel that this feature would make a good contribution because it
mainly requires basic EMF and RCP knowledge.
Would you like to take over this piece? I'd support you and you could
learn about CDO as a side effect...
> There are some special situations that should be managed, like
> recursive dependencies (resource "a" depends on "b", and viceversa) or
> transitive (a depends on b, b on c, c on .....).
Well, this sort of problem should be easy to solve.
> > In fact the title of this Bugzilla should be broadened to "Support
> > external references" since from a repository point of view there won't
> > be much of a difference between references into other repositories and
> > references to any other sort of resources. Feel free to change the
> title
> > and give a short explanation for the record.
> >
>
> Yeah, this situation could also be feasible, I guess at some point
> someone might need to set references in a repo's element to an
> external resource, although I can't imagine a practical situation
> right now.
It's just the same as with multiple respositories.
Why should you want to spread your object graph across resources in
different respositories?
But as always as a framework developer it's sometimes hard to anticipate
other users' situations.
> > Thinking once more I believe that 2) wouldn't really solve your problem
> > since it would import external references into your repository that
> > wouldn't change magically just by importing the referenced resources
> > into the repository!
>
> Yep, It wouldnt, as I explained before.
> >
> > Cheers
> > /Eike
>
> I'll be pleased to help you out with these new requirements (only if
> you find them necessary/useful. I do ;) ), but I'll need some time to
> understand enough of your project architecture :P
Help is always welcome and you'll see that it's fun!
More documentation is a top priority and I'm looking forward to answer
your questions ;-)
Cheers
/Eike
>
> Regards!
>
> Victor.
> Open Canarias.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:38:07 GMT 2024
Powered by FUDForum. Page generated in 0.03607 seconds |
] 
Search
Help
Register
Login
Home
