Home » Modeling » EMF » [CDO] Thread-local legacy mode default
| [CDO] Thread-local legacy mode default [message #919331] |
Fri, 21 September 2012 22:48  |
|
Hi,
Why is the legacy-mode default enablement state that is maintained by
CDOUtil thread-local? This is giving me trouble getting legacy objects
to load in CDOResources loaded by resolution of proxies using
connection-aware URIs.
On the workbench's UI thread, I turn legacy-mode default on. Then I
open a normal EMF-generated editor and expand the content tree until a
proxy using a URI of cdo.net4j.tcp scheme needs to be resolved. This
ends up creating a new CDOView, as I had expected, but it doesn't have
legacy mode enabled because it wasn't created on the UI thread. It was
created on some other thread that my application doesn't have access
to, despite that it's the UI thread that is resolving the proxy.
I can preempt the creation of the view by connecting to the repository
and creating the view on a thread that has default legacy mode, and
this works, but the point of the connection-aware URIs is that the
application doesn't know the repository to connect to until it trips
over a proxy.
What am I missing?
Thanks,
Christian
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #919342 is a reply to message #919331] |
Fri, 21 September 2012 23:02  |
|
Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs
work well for my scenario when I prime the resource set of any
generated EMF editor with a connection to the repository(ies) that it
may need to resolve proxies. So, for my application, I don't actually
need the connection-aware URIs, which avoids the whole problem of
managing the sessions and views that are created automatically.
:-)
I actually have workspace resources that talk to the CDO repo. This is
amazing! It's like a crack team has put years of work into this thing.
cW
On 2012-09-21 22:48:30 +0000, Christian W. Damus said:
> Hi,
>
> Why is the legacy-mode default enablement state that is maintained by
> CDOUtil thread-local? This is giving me trouble getting legacy objects
> to load in CDOResources loaded by resolution of proxies using
> connection-aware URIs.
>
> On the workbench's UI thread, I turn legacy-mode default on. Then I
> open a normal EMF-generated editor and expand the content tree until a
> proxy using a URI of cdo.net4j.tcp scheme needs to be resolved. This
> ends up creating a new CDOView, as I had expected, but it doesn't have
> legacy mode enabled because it wasn't created on the UI thread. It was
> created on some other thread that my application doesn't have access
> to, despite that it's the UI thread that is resolving the proxy.
>
> I can preempt the creation of the view by connecting to the repository
> and creating the view on a thread that has default legacy mode, and
> this works, but the point of the connection-aware URIs is that the
> application doesn't know the repository to connect to until it trips
> over a proxy.
>
> What am I missing?
>
> Thanks,
>
> Christian
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #919614 is a reply to message #919331] |
Sat, 22 September 2012 06:14 |
|
Am 22.09.2012 00:48, schrieb Christian W. Damus:
> Hi,
>
> Why is the legacy-mode default enablement state that is maintained by CDOUtil thread-local? This is giving me trouble
> getting legacy objects to load in CDOResources loaded by resolution of proxies using connection-aware URIs.
>
> On the workbench's UI thread, I turn legacy-mode default on. Then I open a normal EMF-generated editor and expand the
> content tree until a proxy using a URI of cdo.net4j.tcp scheme needs to be resolved. This ends up creating a new
> CDOView, as I had expected, but it doesn't have legacy mode enabled because it wasn't created on the UI thread. It
> was created on some other thread that my application doesn't have access to, despite that it's the UI thread that is
> resolving the proxy.
>
> I can preempt the creation of the view by connecting to the repository and creating the view on a thread that has
> default legacy mode, and this works, but the point of the connection-aware URIs is that the application doesn't know
> the repository to connect to until it trips over a proxy.
>
> What am I missing?
Nothing :P
This is a known issue noone had time, yet, to look at:
363637: [Legacy] Remove thread dependencies from legacy mode control
https://bugs.eclipse.org/bugs/show_bug.cgi?id=363637
I also found this ancient bug that might be relevant in the context of multi-threaded access to legacy objects:
318816: [Legacy] Legacy mode is unreliable in multi-threaded environments
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318816
Not sure if that's still an issue.
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] Thread-local legacy mode default [message #921846 is a reply to message #919614] |
Mon, 24 September 2012 13:36 |
|
Hi, Eike,
Thanks for the reply. I wonder whether the Legacy Mode still needs to
be something that is explicitly enabled. It seems to be quite mature
and working well (with a few issues in UML that can be fixed), and it
interoperates with native models. Why shouldn't it just always be
ready to do its magic?
As far as accessing objects from multiple threads is concerned, I think
that should already be covered by the application I'm dealing with,
because it uses the GMF run-time with its global lock for
synchronization of model reads and updates.
cW
On 2012-09-22 06:14:55 +0000, Eike Stepper said:
> Am 22.09.2012 00:48, schrieb Christian W. Damus:
>> Hi,
>>
>> Why is the legacy-mode default enablement state that is maintained by
>> CDOUtil thread-local? This is giving me trouble getting legacy objects
>> to load in CDOResources loaded by resolution of proxies using
>> connection-aware URIs.
>>
>> On the workbench's UI thread, I turn legacy-mode default on. Then I
>> open a normal EMF-generated editor and expand the content tree until a
>> proxy using a URI of cdo.net4j.tcp scheme needs to be resolved. This
>> ends up creating a new CDOView, as I had expected, but it doesn't have
>> legacy mode enabled because it wasn't created on the UI thread. It was
>> created on some other thread that my application doesn't have access
>> to, despite that it's the UI thread that is resolving the proxy.
>>
>> I can preempt the creation of the view by connecting to the repository
>> and creating the view on a thread that has default legacy mode, and
>> this works, but the point of the connection-aware URIs is that the
>> application doesn't know the repository to connect to until it trips
>> over a proxy.
>>
>> What am I missing?
> Nothing :P
>
> This is a known issue noone had time, yet, to look at:
>
> 363637: [Legacy] Remove thread dependencies from legacy mode control
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=363637
>
> I also found this ancient bug that might be relevant in the context of
> multi-threaded access to legacy objects:
>
> 318816: [Legacy] Legacy mode is unreliable in multi-threaded environments
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=318816
>
> Not sure if that's still an issue.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #921866 is a reply to message #919619] |
Mon, 24 September 2012 13:55 |
|
Hi, Eike,
My experimentation so far has been rather ad hoc. What I've got at the
moment are a collection of context-menu actions that, among other minor
details,
- open a CDOResource in the CDO Sessions view in the UMLEditor (which
I hacked slightly
to allow injection of the CDOTransaction's ResourceSet). This lets
me edit a UML model using
the native child creation menus, property sheet, and actions for
profiles and stereotypes, which is
more convenient than the reflective editor. I can also load
workspace resources and reference
objects in them from my repository objects
- in a UMLEditor, open a session on a CDO repository and open a
transaction on the editor's
resource set. Then, I can resolve any proxies that reference
objects in the repository, and I can
load resources from the repository by entering their "cdo://..."
URIs in the "Load Resource..." dialog
to create new references. Saving the editor triggers commit of the
transaction(s) covering any
dirty CDOResources because that's how CDOResourceImpl does a save
The second action doesn't require any modifications of the UMLEditor as
the first one does. Of course, if I don't first prime the UMLEditor
with this action to give it the CDO context that it needs, then proxies
using the canonical "cdo://..." URIs don't resolve, but that's to be
expected. As it happens, the application I'm dealing with already has
some hooks in its custom resource set that can intercept attempts to
resolve proxies that require CDO repositories that are currently
unavailable, to either connect on the fly or else give the user a more
meaningful error message than "unresolvable proxy".
Of course, the utility of cross-referencing objects in CDO repositories
and the workspace seems dubious to begin with, because the sharing of
changes in the repository is much more immediate than anything you can
do with files in traditional version control systems. But, I want to
account for it as I can think of an edge case or two that would make
sense, even if it implies awkward data integrity questions.
Cheers,
Christian
On 2012-09-22 06:16:55 +0000, Eike Stepper said:
> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs
>> work well for my scenario when I prime the resource set of any
>> generated EMF editor with a connection to the repository(ies) that it
>> may need to resolve proxies. So, for my application, I don't actually
>> need the connection-aware URIs, which avoids the whole problem of
>> managing the sessions and views that are created automatically.
> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>
>> I actually have workspace resources that talk to the CDO repo. This is
>> amazing! It's like a crack team has put years of work into this thing.
> Hehe, that really sounds amazing. Can you elaborate a little on the
> approach you've taken?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #921975 is a reply to message #921846] |
Mon, 24 September 2012 15:59 |
|
Am 24.09.2012 15:36, schrieb Christian W. Damus:
> Hi, Eike,
>
> Thanks for the reply. I wonder whether the Legacy Mode still needs to be something that is explicitly enabled. It
> seems to be quite mature and working well (with a few issues in UML that can be fixed), and it interoperates with
> native models. Why shouldn't it just always be ready to do its magic?
Maturity (or the lack of it) has never been the reason for making legacy support optional. Especially CDO beginners
sometimes forget to regenerate their models for CDO and with the legacy mode popping in automatically they even don't
realize. Only when certain characteristics (e.g. lazy loading) don't meet their expectations they either go away or
repeat questions like "Why is always the complete model loaded?". So we thought it might be good to make the choice for
legacy support explicit.
> As far as accessing objects from multiple threads is concerned, I think that should already be covered by the
> application I'm dealing with, because it uses the GMF run-time with its global lock for synchronization of model reads
> and updates.
I admit that the ThreadLocal approach to the legacy mode control is not optimal. Unfortunately CDOSession has already 10
openView() methods and 10 openTransaction() methods. We'd need another 20 methods if we wanted to control the legacy
mode there. I fear that would create confusion. The addition of a CDOView.setLegacyModeEnabled(boolean) is also
questionable because it really doesn't make sense to have it on or off only for certain periods. But certainly we can
discuss that. The bugzilla would be an adequate forum.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> cW
>
>
> On 2012-09-22 06:14:55 +0000, Eike Stepper said:
>
>> Am 22.09.2012 00:48, schrieb Christian W. Damus:
>>> Hi,
>>>
>>> Why is the legacy-mode default enablement state that is maintained by CDOUtil thread-local? This is giving me
>>> trouble getting legacy objects to load in CDOResources loaded by resolution of proxies using connection-aware URIs.
>>>
>>> On the workbench's UI thread, I turn legacy-mode default on. Then I open a normal EMF-generated editor and expand
>>> the content tree until a proxy using a URI of cdo.net4j.tcp scheme needs to be resolved. This ends up creating a
>>> new CDOView, as I had expected, but it doesn't have legacy mode enabled because it wasn't created on the UI thread.
>>> It was created on some other thread that my application doesn't have access to, despite that it's the UI thread that
>>> is resolving the proxy.
>>>
>>> I can preempt the creation of the view by connecting to the repository and creating the view on a thread that has
>>> default legacy mode, and this works, but the point of the connection-aware URIs is that the application doesn't know
>>> the repository to connect to until it trips over a proxy.
>>>
>>> What am I missing?
>> Nothing :P
>>
>> This is a known issue noone had time, yet, to look at:
>>
>> 363637: [Legacy] Remove thread dependencies from legacy mode control
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=363637
>>
>> I also found this ancient bug that might be relevant in the context of multi-threaded access to legacy objects:
>>
>> 318816: [Legacy] Legacy mode is unreliable in multi-threaded environments
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=318816
>>
>> Not sure if that's still an issue.
>>
>> 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] Thread-local legacy mode default [message #921990 is a reply to message #921866] |
Mon, 24 September 2012 16:20 |
|
Hi Christian,
Thanks for the infos. When you said "I actually have workspace resources that talk to the CDO repo." I thought you're
displaying CDO resources in the platform's resource navigator via CNF or you've implemented an EFS for even deeper
platform integration ;-)
What CDO version are you using for your experiments? Especially the "open editor" story (but also the overall UI
experience) is currently being reworked in 4.2. One goal is to make the newer text and binary resources first class
citizens in the CDO UI, too. They can now be created and opened from the "CDO Sessions" view part. All resources display
with images taken from the platform's editor registry and can be opened with their normal editors. Even traditional
model resources can be opened through a thin EFS layer which emulates XMI resources on the fly (I'm still working on the
creation of relative URIs for cross references). I'm very interested in feedback or additional requirements to make this
more flexible. Please note that CDOSessionsView (an internal class) has also got a small registry for ResourceOpeners
that are selected by resource extension. We could discuss how best to expose it to the public.
You may also find the brand new CDOViewRegistry helpful that assigns IDs to views that are transient, VM-wide unique and
easily serializeable (I needed that to encode transfer data while I implemented drag and drop between CDO and the
workspace or the file system).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 24.09.2012 15:55, schrieb Christian W. Damus:
> Hi, Eike,
>
> My experimentation so far has been rather ad hoc. What I've got at the moment are a collection of context-menu
> actions that, among other minor details,
>
> - open a CDOResource in the CDO Sessions view in the UMLEditor (which I hacked slightly
> to allow injection of the CDOTransaction's ResourceSet). This lets me edit a UML model using
> the native child creation menus, property sheet, and actions for profiles and stereotypes, which is
> more convenient than the reflective editor. I can also load workspace resources and reference
> objects in them from my repository objects
>
> - in a UMLEditor, open a session on a CDO repository and open a transaction on the editor's
> resource set. Then, I can resolve any proxies that reference objects in the repository, and I can
> load resources from the repository by entering their "cdo://..." URIs in the "Load Resource..." dialog
> to create new references. Saving the editor triggers commit of the transaction(s) covering any
> dirty CDOResources because that's how CDOResourceImpl does a save
>
> The second action doesn't require any modifications of the UMLEditor as the first one does. Of course, if I don't
> first prime the UMLEditor with this action to give it the CDO context that it needs, then proxies using the canonical
> "cdo://..." URIs don't resolve, but that's to be expected. As it happens, the application I'm dealing with already
> has some hooks in its custom resource set that can intercept attempts to resolve proxies that require CDO repositories
> that are currently unavailable, to either connect on the fly or else give the user a more meaningful error message
> than "unresolvable proxy".
>
> Of course, the utility of cross-referencing objects in CDO repositories and the workspace seems dubious to begin with,
> because the sharing of changes in the repository is much more immediate than anything you can do with files in
> traditional version control systems. But, I want to account for it as I can think of an edge case or two that would
> make sense, even if it implies awkward data integrity questions.
>
> Cheers,
>
> Christian
>
>
> On 2012-09-22 06:16:55 +0000, Eike Stepper said:
>
>> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs work well for my scenario when I prime the
>>> resource set of any generated EMF editor with a connection to the repository(ies) that it may need to resolve
>>> proxies. So, for my application, I don't actually need the connection-aware URIs, which avoids the whole problem of
>>> managing the sessions and views that are created automatically.
>> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>>
>>> I actually have workspace resources that talk to the CDO repo. This is amazing! It's like a crack team has put
>>> years of work into this thing.
>> Hehe, that really sounds amazing. Can you elaborate a little on the approach you've taken?
>>
>> 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] Thread-local legacy mode default [message #922081 is a reply to message #921990] |
Mon, 24 September 2012 18:11 |
|
Hi, Eike,
See some comments in-line, below.
cW
On 2012-09-24 16:20:29 +0000, Eike Stepper said:
> Hi Christian,
>
> Thanks for the infos. When you said "I actually have workspace
> resources that talk to the CDO repo." I thought you're displaying CDO
> resources in the platform's resource navigator via CNF or you've
> implemented an EFS for even deeper platform integration ;-)
Ha ha. No, I'm not nearly smart enough for that. :-P
> What CDO version are you using for your experiments? Especially the
> "open editor" story (but also the overall UI experience) is currently
> being reworked in 4.2. One goal is to make the newer text and binary
I've got the master branch checked out from Git, as of sometime near
4.2 M1. So, yes, I do see some menu actions relating to text and
binary resources, but I haven't looked into what those are, yet. I
have been meaning to. I'm glad the subject has come up!
So, are these new resources intended to be some kind of blob? Or do
they encapsulate objects that are persisted with distinct identities as
I'm accustomed to from the Juno (4.1) release of CDO?
So far, the management of editors in my application is assumed not to
be leveraging the CDO UI, as there is already a considerable editor
infrastructure in place for some years. But perhaps these new kinds of
resource will help in the integration effort.
> resources first class citizens in the CDO UI, too. They can now be
> created and opened from the "CDO Sessions" view part. All resources
> display with images taken from the platform's editor registry and can
> be opened with their normal editors. Even traditional model resources
> can be opened through a thin EFS layer which emulates XMI resources on
> the fly (I'm still working on the creation of relative URIs for cross
> references). I'm very interested in feedback or additional requirements
> to make this more flexible.
Nice. Is the intention to map a folder/resource tree from the
repository into resources in the Eclipse workspace? That could greatly
simplify the integration of actual workspace resources with repository
resources and maintain consistent workflows for applications like mine
that need to seamlessly work with both modes of persistence.
It seems that the landscape that I'm surveying for my analysis is
changing rapidly as I write! Do you have references to bugzilla or
other documentation that I can look to for background on what these new
resources are for?
> Please note that CDOSessionsView (an internal class) has also got a
> small registry for ResourceOpeners that are selected by resource
> extension. We could discuss how best to expose it to the public.
Oh, that's cool. I did not know about this. So, it wouldn't be a
stretch to associate CDOResources (presumably matching some criteria of
name and/or contents) to editors? Most generated editors, though,
create their own resource sets. I'm not sure how this would work ...
> You may also find the brand new CDOViewRegistry helpful that assigns
> IDs to views that are transient, VM-wide unique and easily
> serializeable (I needed that to encode transfer data while I
> implemented drag and drop between CDO and the workspace or the file
> system).
Hmm. I'll have a look. So much to explore, that I don't even know
exists ... :-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 24.09.2012 15:55, schrieb Christian W. Damus:
>> Hi, Eike,
>>
>> My experimentation so far has been rather ad hoc. What I've got at the
>> moment are a collection of context-menu actions that, among other minor
>> details,
>>
>> - open a CDOResource in the CDO Sessions view in the UMLEditor (which I
>> hacked slightly
>> to allow injection of the CDOTransaction's ResourceSet). This lets me
>> edit a UML model using
>> the native child creation menus, property sheet, and actions for
>> profiles and stereotypes, which is
>> more convenient than the reflective editor. I can also load workspace
>> resources and reference
>> objects in them from my repository objects
>>
>> - in a UMLEditor, open a session on a CDO repository and open a
>> transaction on the editor's
>> resource set. Then, I can resolve any proxies that reference objects
>> in the repository, and I can
>> load resources from the repository by entering their "cdo://..." URIs
>> in the "Load Resource..." dialog
>> to create new references. Saving the editor triggers commit of the
>> transaction(s) covering any
>> dirty CDOResources because that's how CDOResourceImpl does a save
>>
>> The second action doesn't require any modifications of the UMLEditor as
>> the first one does. Of course, if I don't first prime the UMLEditor
>> with this action to give it the CDO context that it needs, then proxies
>> using the canonical "cdo://..." URIs don't resolve, but that's to be
>> expected. As it happens, the application I'm dealing with already has
>> some hooks in its custom resource set that can intercept attempts to
>> resolve proxies that require CDO repositories that are currently
>> unavailable, to either connect on the fly or else give the user a more
>> meaningful error message than "unresolvable proxy".
>>
>> Of course, the utility of cross-referencing objects in CDO repositories
>> and the workspace seems dubious to begin with, because the sharing of
>> changes in the repository is much more immediate than anything you can
>> do with files in traditional version control systems. But, I want to
>> account for it as I can think of an edge case or two that would make
>> sense, even if it implies awkward data integrity questions.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> On 2012-09-22 06:16:55 +0000, Eike Stepper said:
>>
>>> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>>>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs
>>>> work well for my scenario when I prime the resource set of any
>>>> generated EMF editor with a connection to the repository(ies) that it
>>>> may need to resolve proxies. So, for my application, I don't actually
>>>> need the connection-aware URIs, which avoids the whole problem of
>>>> managing the sessions and views that are created automatically.
>>> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>>>
>>>> I actually have workspace resources that talk to the CDO repo. This is
>>>> amazing! It's like a crack team has put years of work into this thing.
>>> Hehe, that really sounds amazing. Can you elaborate a little on the
>>> approach you've taken?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #922113 is a reply to message #922081] |
Mon, 24 September 2012 18:55 |
|
Am 24.09.2012 20:11, schrieb Christian W. Damus:
> Hi, Eike,
>
> See some comments in-line, below.
>
> cW
>
> On 2012-09-24 16:20:29 +0000, Eike Stepper said:
>
>> Hi Christian,
>>
>> Thanks for the infos. When you said "I actually have workspace resources that talk to the CDO repo." I thought you're
>> displaying CDO resources in the platform's resource navigator via CNF or you've implemented an EFS for even deeper
>> platform integration ;-)
>
> Ha ha. No, I'm not nearly smart enough for that. :-P
I know you are ;-)
>
>
>> What CDO version are you using for your experiments? Especially the "open editor" story (but also the overall UI
>> experience) is currently being reworked in 4.2. One goal is to make the newer text and binary
>
> I've got the master branch checked out from Git, as of sometime near 4.2 M1.
Many of the things I mentioned are even newer than that. But M2 is near (if you don't dare to checkout the tip of master).
> So, yes, I do see some menu actions relating to text and binary resources, but I haven't looked into what those are,
> yet. I have been meaning to. I'm glad the subject has come up!
>
> So, are these new resources intended to be some kind of blob? Or do they encapsulate objects that are persisted with
> distinct identities as I'm accustomed to from the Juno (4.1) release of CDO?
Not sure what the latter means but, regarding the former, yes. CDOBinaryResource is a CDOResourceLeaf with a
CDOBlob-typed contents attribute and CDOTextResource is a leaf with a CDOClob-typed contents attribute and an encoding
attribute. These special large object EDataTypes come from CDO's Etypes system package and support streaming directly
between the database and the user application. A CDOLob<?> is identified by a digest of its content. That enables reuse
in multiple EObjects and client-side caching. The idea is that each lob is only ever transfered once over the wire
(similar to how Git addresses blobs).
> So far, the management of editors in my application is assumed not to be leveraging the CDO UI, as there is already a
> considerable editor infrastructure in place for some years. But perhaps these new kinds of resource will help in the
> integration effort.
>
>
>> resources first class citizens in the CDO UI, too. They can now be created and opened from the "CDO Sessions" view
>> part. All resources display with images taken from the platform's editor registry and can be opened with their normal
>> editors. Even traditional model resources can be opened through a thin EFS layer which emulates XMI resources on the
>> fly (I'm still working on the creation of relative URIs for cross references). I'm very interested in feedback or
>> additional requirements to make this more flexible.
>
> Nice. Is the intention to map a folder/resource tree from the repository into resources in the Eclipse workspace?
> That could greatly simplify the integration of actual workspace resources with repository resources and maintain
> consistent workflows for applications like mine that need to seamlessly work with both modes of persistence.
Not really. We do have kind of a prototype of what you describe (a CDO-based EFS implementation). But it's quite complex
because of the basic premise of the EFS framework that everything is stateless, cheap to create and that there's no
multi-resource save context. I don't think it's in a shape ready for production usage.
> It seems that the landscape that I'm surveying for my analysis is changing rapidly as I write! Do you have references
> to bugzilla or other documentation that I can look to for background on what these new resources are for?
284307: Add support for streaming of large byte arrays / BLOB
https://bugs.eclipse.org/bugs/show_bug.cgi?id=284307
Here's a test for general lob usage:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/LobTest.java
362982: Add CDOTextResource and CDOBinaryResource
https://bugs.eclipse.org/bugs/show_bug.cgi?id=362982
Here's the CDO provider of the new resource transfer framework. It uses text and binary resources directly:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.transfer.repository/src/org/eclipse/emf/cdo/transfer/spi/repository/RepositoryTransferSystem.java
This diagram may be of interest, too:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/model/eresource.ecorediag
>
>
>> Please note that CDOSessionsView (an internal class) has also got a small registry for ResourceOpeners that are
>> selected by resource extension. We could discuss how best to expose it to the public.
>
> Oh, that's cool. I did not know about this. So, it wouldn't be a stretch to associate CDOResources (presumably
> matching some criteria of name and/or contents) to editors? Most generated editors, though, create their own resource
> sets. I'm not sure how this would work ...
Please have a look at this RFE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=384036
And nag Ed to get it in quickly, if you like it ;-)
>
>
>> You may also find the brand new CDOViewRegistry helpful that assigns IDs to views that are transient, VM-wide unique
>> and easily serializeable (I needed that to encode transfer data while I implemented drag and drop between CDO and the
>> workspace or the file system).
>
> Hmm. I'll have a look. So much to explore, that I don't even know exists ... :-)
Yeah, the deficiencies are more in the documentation area :P
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
>>
>>
>>
>> Am 24.09.2012 15:55, schrieb Christian W. Damus:
>>> Hi, Eike,
>>>
>>> My experimentation so far has been rather ad hoc. What I've got at the moment are a collection of context-menu
>>> actions that, among other minor details,
>>>
>>> - open a CDOResource in the CDO Sessions view in the UMLEditor (which I hacked slightly
>>> to allow injection of the CDOTransaction's ResourceSet). This lets me edit a UML model using
>>> the native child creation menus, property sheet, and actions for profiles and stereotypes, which is
>>> more convenient than the reflective editor. I can also load workspace resources and reference
>>> objects in them from my repository objects
>>>
>>> - in a UMLEditor, open a session on a CDO repository and open a transaction on the editor's
>>> resource set. Then, I can resolve any proxies that reference objects in the repository, and I can
>>> load resources from the repository by entering their "cdo://..." URIs in the "Load Resource..." dialog
>>> to create new references. Saving the editor triggers commit of the transaction(s) covering any
>>> dirty CDOResources because that's how CDOResourceImpl does a save
>>>
>>> The second action doesn't require any modifications of the UMLEditor as the first one does. Of course, if I don't
>>> first prime the UMLEditor with this action to give it the CDO context that it needs, then proxies using the
>>> canonical "cdo://..." URIs don't resolve, but that's to be expected. As it happens, the application I'm dealing
>>> with already has some hooks in its custom resource set that can intercept attempts to resolve proxies that require
>>> CDO repositories that are currently unavailable, to either connect on the fly or else give the user a more
>>> meaningful error message than "unresolvable proxy".
>>>
>>> Of course, the utility of cross-referencing objects in CDO repositories and the workspace seems dubious to begin
>>> with, because the sharing of changes in the repository is much more immediate than anything you can do with files in
>>> traditional version control systems. But, I want to account for it as I can think of an edge case or two that would
>>> make sense, even if it implies awkward data integrity questions.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> On 2012-09-22 06:16:55 +0000, Eike Stepper said:
>>>
>>>> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>>>>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs work well for my scenario when I prime the
>>>>> resource set of any generated EMF editor with a connection to the repository(ies) that it may need to resolve
>>>>> proxies. So, for my application, I don't actually need the connection-aware URIs, which avoids the whole problem
>>>>> of managing the sessions and views that are created automatically.
>>>> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>>>>
>>>>> I actually have workspace resources that talk to the CDO repo. This is amazing! It's like a crack team has put
>>>>> years of work into this thing.
>>>> Hehe, that really sounds amazing. Can you elaborate a little on the approach you've taken?
>>>>
>>>> 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] Thread-local legacy mode default [message #925270 is a reply to message #922113] |
Thu, 27 September 2012 14:55 |
|
Thanks, Eike, for all of the references.
So, it seems to me that the CDOTextResource and CDOBinaryResource let
us persist resources as atoms in the repository, in much the same way
that a file-based version control system does, except of course with
the usual benefits of CDO's notifications to connected clients, etc.
But, these resources are atoms, so the objects that they contain don't
benefit from CDO's scalability features (which legacy mode mostly
doesn't support, anyways), fine-grained locking, auditing, etc. Is
this an accurate understanding?
If so, then I think these resources will be useful for
"attachment"-type properties of model elements, but probably not as a
general solution for model persistence. At least, they wouldn't
realize the benefits that I hope to achieve by porting a modeling tool
from files to CDO in the first place. Does this conclusion jive with
your goals for these new resources?
cW
On 2012-09-24 18:55:01 +0000, Eike Stepper said:
> Am 24.09.2012 20:11, schrieb Christian W. Damus:
>> Hi, Eike,
>>
>> See some comments in-line, below.
>>
>> cW
>>
>> On 2012-09-24 16:20:29 +0000, Eike Stepper said:
>>
>>> Hi Christian,
>>>
>>> Thanks for the infos. When you said "I actually have workspace
>>> resources that talk to the CDO repo." I thought you're displaying CDO
>>> resources in the platform's resource navigator via CNF or you've
>>> implemented an EFS for even deeper platform integration ;-)
>>
>> Ha ha. No, I'm not nearly smart enough for that. :-P
> I know you are ;-)
>
>>
>>
>>> What CDO version are you using for your experiments? Especially the
>>> "open editor" story (but also the overall UI experience) is currently
>>> being reworked in 4.2. One goal is to make the newer text and binary
>>
>> I've got the master branch checked out from Git, as of sometime near 4.2 M1.
> Many of the things I mentioned are even newer than that. But M2 is near
> (if you don't dare to checkout the tip of master).
>
>> So, yes, I do see some menu actions relating to text and binary
>> resources, but I haven't looked into what those are, yet. I have been
>> meaning to. I'm glad the subject has come up!
>>
>> So, are these new resources intended to be some kind of blob? Or do
>> they encapsulate objects that are persisted with distinct identities as
>> I'm accustomed to from the Juno (4.1) release of CDO?
> Not sure what the latter means but, regarding the former, yes.
> CDOBinaryResource is a CDOResourceLeaf with a CDOBlob-typed contents
> attribute and CDOTextResource is a leaf with a CDOClob-typed contents
> attribute and an encoding attribute. These special large object
> EDataTypes come from CDO's Etypes system package and support streaming
> directly between the database and the user application. A CDOLob<?> is
> identified by a digest of its content. That enables reuse in multiple
> EObjects and client-side caching. The idea is that each lob is only
> ever transfered once over the wire (similar to how Git addresses blobs).
>
>> So far, the management of editors in my application is assumed not to
>> be leveraging the CDO UI, as there is already a considerable editor
>> infrastructure in place for some years. But perhaps these new kinds of
>> resource will help in the integration effort.
>>
>>
>>> resources first class citizens in the CDO UI, too. They can now be
>>> created and opened from the "CDO Sessions" view part. All resources
>>> display with images taken from the platform's editor registry and can
>>> be opened with their normal editors. Even traditional model resources
>>> can be opened through a thin EFS layer which emulates XMI resources on
>>> the fly (I'm still working on the creation of relative URIs for cross
>>> references). I'm very interested in feedback or additional requirements
>>> to make this more flexible.
>>
>> Nice. Is the intention to map a folder/resource tree from the
>> repository into resources in the Eclipse workspace? That could greatly
>> simplify the integration of actual workspace resources with repository
>> resources and maintain consistent workflows for applications like mine
>> that need to seamlessly work with both modes of persistence.
> Not really. We do have kind of a prototype of what you describe (a
> CDO-based EFS implementation). But it's quite complex because of the
> basic premise of the EFS framework that everything is stateless, cheap
> to create and that there's no multi-resource save context. I don't
> think it's in a shape ready for production usage.
>
>> It seems that the landscape that I'm surveying for my analysis is
>> changing rapidly as I write! Do you have references to bugzilla or
>> other documentation that I can look to for background on what these new
>> resources are for?
> 284307: Add support for streaming of large byte arrays / BLOB
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=284307
>
> Here's a test for general lob usage:
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/LobTest.java
>
>
> 362982: Add CDOTextResource and CDOBinaryResource
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=362982
>
> Here's the CDO provider of the new resource transfer framework. It uses
> text and binary resources directly:
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.transfer.repository/src/org/eclipse/emf/cdo/transfer/spi/repository/RepositoryTransferSystem.java
>
>
> This diagram may be of interest, too:
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/model/eresource.ecorediag
>
>
>>
>>
>>> Please note that CDOSessionsView (an internal class) has also got a
>>> small registry for ResourceOpeners that are selected by resource
>>> extension. We could discuss how best to expose it to the public.
>>
>> Oh, that's cool. I did not know about this. So, it wouldn't be a
>> stretch to associate CDOResources (presumably matching some criteria of
>> name and/or contents) to editors? Most generated editors, though,
>> create their own resource sets. I'm not sure how this would work ...
> Please have a look at this RFE:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=384036
>
> And nag Ed to get it in quickly, if you like it ;-)
>
>>
>>
>>> You may also find the brand new CDOViewRegistry helpful that assigns
>>> IDs to views that are transient, VM-wide unique and easily
>>> serializeable (I needed that to encode transfer data while I
>>> implemented drag and drop between CDO and the workspace or the file
>>> system).
>>
>> Hmm. I'll have a look. So much to explore, that I don't even know
>> exists ... :-)
> Yeah, the deficiencies are more in the documentation area :P
>
> 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
>>>
>>>
>>>
>>> Am 24.09.2012 15:55, schrieb Christian W. Damus:
>>>> Hi, Eike,
>>>>
>>>> My experimentation so far has been rather ad hoc. What I've got at the
>>>> moment are a collection of context-menu actions that, among other minor
>>>> details,
>>>>
>>>> - open a CDOResource in the CDO Sessions view in the UMLEditor (which I
>>>> hacked slightly
>>>> to allow injection of the CDOTransaction's ResourceSet). This lets me
>>>> edit a UML model using
>>>> the native child creation menus, property sheet, and actions for
>>>> profiles and stereotypes, which is
>>>> more convenient than the reflective editor. I can also load workspace
>>>> resources and reference
>>>> objects in them from my repository objects
>>>>
>>>> - in a UMLEditor, open a session on a CDO repository and open a
>>>> transaction on the editor's
>>>> resource set. Then, I can resolve any proxies that reference objects
>>>> in the repository, and I can
>>>> load resources from the repository by entering their "cdo://..." URIs
>>>> in the "Load Resource..." dialog
>>>> to create new references. Saving the editor triggers commit of the
>>>> transaction(s) covering any
>>>> dirty CDOResources because that's how CDOResourceImpl does a save
>>>>
>>>> The second action doesn't require any modifications of the UMLEditor as
>>>> the first one does. Of course, if I don't first prime the UMLEditor
>>>> with this action to give it the CDO context that it needs, then proxies
>>>> using the canonical "cdo://..." URIs don't resolve, but that's to be
>>>> expected. As it happens, the application I'm dealing with already has
>>>> some hooks in its custom resource set that can intercept attempts to
>>>> resolve proxies that require CDO repositories that are currently
>>>> unavailable, to either connect on the fly or else give the user a more
>>>> meaningful error message than "unresolvable proxy".
>>>>
>>>> Of course, the utility of cross-referencing objects in CDO repositories
>>>> and the workspace seems dubious to begin with, because the sharing of
>>>> changes in the repository is much more immediate than anything you can
>>>> do with files in traditional version control systems. But, I want to
>>>> account for it as I can think of an edge case or two that would make
>>>> sense, even if it implies awkward data integrity questions.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 2012-09-22 06:16:55 +0000, Eike Stepper said:
>>>>
>>>>> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>>>>>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs
>>>>>> work well for my scenario when I prime the resource set of any
>>>>>> generated EMF editor with a connection to the repository(ies) that it
>>>>>> may need to resolve proxies. So, for my application, I don't actually
>>>>>> need the connection-aware URIs, which avoids the whole problem of
>>>>>> managing the sessions and views that are created automatically.
>>>>> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>>>>>
>>>>>> I actually have workspace resources that talk to the CDO repo. This is
>>>>>> amazing! It's like a crack team has put years of work into this thing.
>>>>> Hehe, that really sounds amazing. Can you elaborate a little on the
>>>>> approach you've taken?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://www.esc-net.de
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Thread-local legacy mode default [message #925902 is a reply to message #925270] |
Fri, 28 September 2012 05:56 |
|
Am 27.09.2012 16:55, schrieb Christian W. Damus:
> Thanks, Eike, for all of the references.
>
> So, it seems to me that the CDOTextResource and CDOBinaryResource let us persist resources as atoms in the repository,
> in much the same way that a file-based version control system does, except of course with the usual benefits of CDO's
> notifications to connected clients, etc.
Exactly.
> But, these resources are atoms, so the objects that they contain
If they contain objects. They're meant more to store non-modeled contents, e.g., all files of an IProject that no
Resource.Factories are associated with (.project, build.properties, Java sources or images).
> don't benefit from CDO's scalability features (which legacy mode mostly doesn't support, anyways), fine-grained
> locking, auditing, etc. Is this an accurate understanding?
Mostly. Auditing and branching are supported, though.
> If so, then I think these resources will be useful for "attachment"-type properties of model elements,
For example. Although, if you have control over your meta model, you can also add Blob/Clob-typed attributes to your own
EClasses rather then pointing to those in the special CDOText/BinaryResource objects.
> but probably not as a general solution for model persistence.
No, models should be stored in CDO(Model)Resources.
> At least, they wouldn't realize the benefits that I hope to achieve by porting a modeling tool from files to CDO in
> the first place. Does this conclusion jive with your goals for these new resources?
I think so ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> cW
>
>
> On 2012-09-24 18:55:01 +0000, Eike Stepper said:
>
>> Am 24.09.2012 20:11, schrieb Christian W. Damus:
>>> Hi, Eike,
>>>
>>> See some comments in-line, below.
>>>
>>> cW
>>>
>>> On 2012-09-24 16:20:29 +0000, Eike Stepper said:
>>>
>>>> Hi Christian,
>>>>
>>>> Thanks for the infos. When you said "I actually have workspace resources that talk to the CDO repo." I thought
>>>> you're displaying CDO resources in the platform's resource navigator via CNF or you've implemented an EFS for even
>>>> deeper platform integration ;-)
>>>
>>> Ha ha. No, I'm not nearly smart enough for that. :-P
>> I know you are ;-)
>>
>>>
>>>
>>>> What CDO version are you using for your experiments? Especially the "open editor" story (but also the overall UI
>>>> experience) is currently being reworked in 4.2. One goal is to make the newer text and binary
>>>
>>> I've got the master branch checked out from Git, as of sometime near 4.2 M1.
>> Many of the things I mentioned are even newer than that. But M2 is near (if you don't dare to checkout the tip of
>> master).
>>
>>> So, yes, I do see some menu actions relating to text and binary resources, but I haven't looked into what those are,
>>> yet. I have been meaning to. I'm glad the subject has come up!
>>>
>>> So, are these new resources intended to be some kind of blob? Or do they encapsulate objects that are persisted with
>>> distinct identities as I'm accustomed to from the Juno (4.1) release of CDO?
>> Not sure what the latter means but, regarding the former, yes. CDOBinaryResource is a CDOResourceLeaf with a
>> CDOBlob-typed contents attribute and CDOTextResource is a leaf with a CDOClob-typed contents attribute and an
>> encoding attribute. These special large object EDataTypes come from CDO's Etypes system package and support streaming
>> directly between the database and the user application. A CDOLob<?> is identified by a digest of its content. That
>> enables reuse in multiple EObjects and client-side caching. The idea is that each lob is only ever transfered once
>> over the wire (similar to how Git addresses blobs).
>>
>>> So far, the management of editors in my application is assumed not to be leveraging the CDO UI, as there is already
>>> a considerable editor infrastructure in place for some years. But perhaps these new kinds of resource will help in
>>> the integration effort.
>>>
>>>
>>>> resources first class citizens in the CDO UI, too. They can now be created and opened from the "CDO Sessions" view
>>>> part. All resources display with images taken from the platform's editor registry and can be opened with their
>>>> normal editors. Even traditional model resources can be opened through a thin EFS layer which emulates XMI
>>>> resources on the fly (I'm still working on the creation of relative URIs for cross references). I'm very interested
>>>> in feedback or additional requirements to make this more flexible.
>>>
>>> Nice. Is the intention to map a folder/resource tree from the repository into resources in the Eclipse workspace?
>>> That could greatly simplify the integration of actual workspace resources with repository resources and maintain
>>> consistent workflows for applications like mine that need to seamlessly work with both modes of persistence.
>> Not really. We do have kind of a prototype of what you describe (a CDO-based EFS implementation). But it's quite
>> complex because of the basic premise of the EFS framework that everything is stateless, cheap to create and that
>> there's no multi-resource save context. I don't think it's in a shape ready for production usage.
>>
>>> It seems that the landscape that I'm surveying for my analysis is changing rapidly as I write! Do you have
>>> references to bugzilla or other documentation that I can look to for background on what these new resources are for?
>> 284307: Add support for streaming of large byte arrays / BLOB
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=284307
>>
>> Here's a test for general lob usage:
>> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/LobTest.java
>>
>> 362982: Add CDOTextResource and CDOBinaryResource
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=362982
>>
>> Here's the CDO provider of the new resource transfer framework. It uses text and binary resources directly:
>> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.transfer.repository/src/org/eclipse/emf/cdo/transfer/spi/repository/RepositoryTransferSystem.java
>>
>>
>> This diagram may be of interest, too:
>> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/model/eresource.ecorediag
>>
>>>
>>>
>>>> Please note that CDOSessionsView (an internal class) has also got a small registry for ResourceOpeners that are
>>>> selected by resource extension. We could discuss how best to expose it to the public.
>>>
>>> Oh, that's cool. I did not know about this. So, it wouldn't be a stretch to associate CDOResources (presumably
>>> matching some criteria of name and/or contents) to editors? Most generated editors, though, create their own
>>> resource sets. I'm not sure how this would work ...
>> Please have a look at this RFE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=384036
>>
>> And nag Ed to get it in quickly, if you like it ;-)
>>
>>>
>>>
>>>> You may also find the brand new CDOViewRegistry helpful that assigns IDs to views that are transient, VM-wide
>>>> unique and easily serializeable (I needed that to encode transfer data while I implemented drag and drop between
>>>> CDO and the workspace or the file system).
>>>
>>> Hmm. I'll have a look. So much to explore, that I don't even know exists ... :-)
>> Yeah, the deficiencies are more in the documentation area :P
>>
>> 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
>>>>
>>>>
>>>>
>>>> Am 24.09.2012 15:55, schrieb Christian W. Damus:
>>>>> Hi, Eike,
>>>>>
>>>>> My experimentation so far has been rather ad hoc. What I've got at the moment are a collection of context-menu
>>>>> actions that, among other minor details,
>>>>>
>>>>> - open a CDOResource in the CDO Sessions view in the UMLEditor (which I hacked slightly
>>>>> to allow injection of the CDOTransaction's ResourceSet). This lets me edit a UML model using
>>>>> the native child creation menus, property sheet, and actions for profiles and stereotypes, which is
>>>>> more convenient than the reflective editor. I can also load workspace resources and reference
>>>>> objects in them from my repository objects
>>>>>
>>>>> - in a UMLEditor, open a session on a CDO repository and open a transaction on the editor's
>>>>> resource set. Then, I can resolve any proxies that reference objects in the repository, and I can
>>>>> load resources from the repository by entering their "cdo://..." URIs in the "Load Resource..." dialog
>>>>> to create new references. Saving the editor triggers commit of the transaction(s) covering any
>>>>> dirty CDOResources because that's how CDOResourceImpl does a save
>>>>>
>>>>> The second action doesn't require any modifications of the UMLEditor as the first one does. Of course, if I don't
>>>>> first prime the UMLEditor with this action to give it the CDO context that it needs, then proxies using the
>>>>> canonical "cdo://..." URIs don't resolve, but that's to be expected. As it happens, the application I'm dealing
>>>>> with already has some hooks in its custom resource set that can intercept attempts to resolve proxies that require
>>>>> CDO repositories that are currently unavailable, to either connect on the fly or else give the user a more
>>>>> meaningful error message than "unresolvable proxy".
>>>>>
>>>>> Of course, the utility of cross-referencing objects in CDO repositories and the workspace seems dubious to begin
>>>>> with, because the sharing of changes in the repository is much more immediate than anything you can do with files
>>>>> in traditional version control systems. But, I want to account for it as I can think of an edge case or two that
>>>>> would make sense, even if it implies awkward data integrity questions.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On 2012-09-22 06:16:55 +0000, Eike Stepper said:
>>>>>
>>>>>> Am 22.09.2012 01:02, schrieb Christian W. Damus:
>>>>>>> Actually, the canonical cdo://<repo-uuid>/path/to/resource#<OID> URIs work well for my scenario when I prime the
>>>>>>> resource set of any generated EMF editor with a connection to the repository(ies) that it may need to resolve
>>>>>>> proxies. So, for my application, I don't actually need the connection-aware URIs, which avoids the whole
>>>>>>> problem of managing the sessions and views that are created automatically.
>>>>>> Yeah, it's a pity that ResourceSet does not provide lifecycle hooks ;-(
>>>>>>
>>>>>>> I actually have workspace resources that talk to the CDO repo. This is amazing! It's like a crack team has put
>>>>>>> years of work into this thing.
>>>>>> Hehe, that really sounds amazing. Can you elaborate a little on the approach you've taken?
>>>>>>
>>>>>> 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] Thread-local legacy mode default [message #926262 is a reply to message #925902] |
Fri, 28 September 2012 13:19 |
|
Thanks, Eike!
That's all clear. We're on the same page. :-)
cW
On 2012-09-28 05:56:30 +0000, Eike Stepper said:
> Am 27.09.2012 16:55, schrieb Christian W. Damus:
>> Thanks, Eike, for all of the references.
>>
>> So, it seems to me that the CDOTextResource and CDOBinaryResource let
>> us persist resources as atoms in the repository, in much the same way
>> that a file-based version control system does, except of course with
>> the usual benefits of CDO's notifications to connected clients, etc.
> Exactly.
>
>> But, these resources are atoms, so the objects that they contain
> If they contain objects. They're meant more to store non-modeled
> contents, e.g., all files of an IProject that no Resource.Factories are
> associated with (.project, build.properties, Java sources or images).
>
>> don't benefit from CDO's scalability features (which legacy mode mostly
>> doesn't support, anyways), fine-grained locking, auditing, etc. Is this
>> an accurate understanding?
> Mostly. Auditing and branching are supported, though.
>
>> If so, then I think these resources will be useful for
>> "attachment"-type properties of model elements,
> For example. Although, if you have control over your meta model, you
> can also add Blob/Clob-typed attributes to your own EClasses rather
> then pointing to those in the special CDOText/BinaryResource objects.
>
>> but probably not as a general solution for model persistence.
> No, models should be stored in CDO(Model)Resources.
>
>> At least, they wouldn't realize the benefits that I hope to achieve by
>> porting a modeling tool from files to CDO in the first place. Does this
>> conclusion jive with your goals for these new resources?
> I think so ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
-------- 8< --------
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:01:28 GMT 2024
Powered by FUDForum. Page generated in 0.04070 seconds |
] 
Search
Help
Register
Login
Home
