Home » Modeling » EMF » SDO and Transaction
| SDO and Transaction [message #415677] |
Fri, 28 December 2007 01:15  |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
I have a use case for supporting disconnected clients from a common
desktop user running a transactional editor.
What I am looking for is to have a client import a resource from the
transactional editor, disconnect, updated the instance and create a SDO
Data graph, reconnect and import it back into a Transactional Editor in
order to update its model.
Does the above scenario make sense?
If so are there any plans to provide such an interaction between EMF
Transaction components and SDO in the future?
thanks,
John
|
|
| |
| Re: SDO and Transaction [message #415686 is a reply to message #415679] |
Fri, 28 December 2007 22:43  |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Ed,
See in-line...
Ed Merks wrote:
> John,
>
> I'm not sure SDO is needed for such a scenario. An editor can load a
> resource from any URI, including HTTP-based ones. In addition, the URI
> converter can be specialized to access data that's not accessible via a
> real live URL. The URIConverter APIs were enhanced in 2.4 so that even
> things like delete are possible;
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 contains a simple
> servlet to test save and delete via HTTP.
Yes, I saw the previous thread relating to your work on the servlet.
Downloaded and took a look at the code for the servlet and the changes
in the M4 build. Nice.
> At any time you can unload a
> resource to discard it's contents and reload it from the backing store;
> that's what happens if there's a resource delta in the workspace via
> another editor.
So when I have multiple clients that have loaded resources from the
backing store and any one changes something, the others could be
signaled (SomeHow ?) to unload and reload. Right?
> SDO's change summary is implemented by EMF's Change
> model which supports recording all changes made to a model and can
> represent those changes as a change description which is itself a model
> that can be transmitted back to the server. Such a mechanism might be
> used to transmit only delta between the client and the server rather
> than the whole model.
Have used org.eclipse.emf.transaction.RecordingCommand to update my
model instances but, know very little about the 'EMF Change Model' but
do see it referenced in
org.eclipse.emf.transaction.util.CompositeChangeDescription.
If this what I would use to record changes in my client, are there
existing ways to update my model instances with it?
Tangent: In googling for 'EMF Change Model' I ran across:
http://safari.oreilly.com/9780321331885/ch17
A preview snippet from chapter 17 of your EMF: Eclipse Modeling
Framework, Second Edition. Will it be available like Orielly says in
February?
>
> John E. Conlon wrote:
>> I have a use case for supporting disconnected clients from a common
>> desktop user running a transactional editor.
>>
>>
>> What I am looking for is to have a client import a resource from the
>> transactional editor, disconnect, updated the instance and create a
>> SDO Data graph, reconnect and import it back into a Transactional
>> Editor in order to update its model.
>>
>> Does the above scenario make sense?
>>
>> If so are there any plans to provide such an interaction between EMF
>> Transaction components and SDO in the future?
>>
thanks again for the support Ed, Happy New Year,
John
|
|
|
| Re: SDO and Transaction [message #415688 is a reply to message #415686] |
Sat, 29 December 2007 12:50 |
 Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
John,
Comments below.
John E. Conlon wrote:
> Hi Ed,
>
> See in-line...
>
> Ed Merks wrote:
>> John,
>>
>> I'm not sure SDO is needed for such a scenario. An editor can load a
>> resource from any URI, including HTTP-based ones. In addition, the
>> URI converter can be specialized to access data that's not accessible
>> via a real live URL. The URIConverter APIs were enhanced in 2.4 so
>> that even things like delete are possible;
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 contains a
>> simple servlet to test save and delete via HTTP.
>
> Yes, I saw the previous thread relating to your work on the servlet.
>
> Downloaded and took a look at the code for the servlet and the changes
> in the M4 build. Nice.
>> At any time you can unload a
>> resource to discard it's contents and reload it from the backing
>> store; that's what happens if there's a resource delta in the
>> workspace via another editor.
> So when I have multiple clients that have loaded resources from the
> backing store and any one changes something, the others could be
> signaled (SomeHow ?) to unload and reload. Right?
That one reasonable approach. Of course getting a backing store to send
notifications about changes is something you'd need to hook up. Another
approach is that clients could poll for changes (as you'd do for CVS).
With EMF 2.4 a resource keeps track of the timestamp of the resource it
loads and can check that timestamp against the timestamp in the backing
store to do optimistic concurrency. There's also generalized support
for getting and setting attributes of a URI, so it would be possible via
extensions, for example to lock a resource and find out if it's locked.
Note that the CDO component of EMFT supports true concurrent editing of
a shared server-based instance, so that might interest you a lot. The
clients basically make use of EMF's Store APIs so that the EObjects on
the client side act as thin shadows/wrappers that delegate all data
access to a master backing store on the server. It's also fully lazy in
that shadows on the client are created only as the data is accessed.
When a modification is made, all clients are notified and can update
their view. It's very cool stuff.
>
>
>> SDO's change summary is implemented by EMF's Change
>> model which supports recording all changes made to a model and can
>> represent those changes as a change description which is itself a
>> model that can be transmitted back to the server. Such a mechanism
>> might be used to transmit only delta between the client and the
>> server rather than the whole model.
>
> Have used org.eclipse.emf.transaction.RecordingCommand to update my
> model instances but, know very little about the 'EMF Change Model' but
> do see it referenced in
> org.eclipse.emf.transaction.util.CompositeChangeDescription.
> If this what I would use to record changes in my client, are there
> existing ways to update my model instances with it?
Looking at the ChangeRecordTest in our JUnits show the basic
functioning. If you search the newsgroup history you'll see I
described it's use a few times. It's really quite simple. You hook up
a ChangeRecorder to the objects that will be changed (e.g., you can hook
it up to the whole resource set with a single line of code) and then it
monitors changes. At any point you can call endRecording to produce a
ChangeDescription which is a model instance that specifies exactly what
needs to be done to get the model from its current state back to its
original state; you can call applyAndReverse to do exactly that and end
up with a ChangeDescription which specifies how to get from the original
state to the final state. Such a forward delta you could then send to
the server where it too could call apply to get the server copy to the
same state.
>
> Tangent: In googling for 'EMF Change Model' I ran across:
> http://safari.oreilly.com/9780321331885/ch17
> A preview snippet from chapter 17 of your EMF: Eclipse Modeling
> Framework, Second Edition. Will it be available like Orielly says in
> February?
Yes, the second edition of the EMF book is now available as a rough cut
(an in progress draft) at Safari! I'm really hoping it will be in print
in time for EclipseCon, but certainly I expect it will be complete
online in February. Unfortunately it's taken a lot longer than planned
and as a result it's taking even longer because we need to add quite a
bit of material to cover what was introduce for EMF 2.3.
>
>
>>
>> John E. Conlon wrote:
>>> I have a use case for supporting disconnected clients from a common
>>> desktop user running a transactional editor.
>>>
>>>
>>> What I am looking for is to have a client import a resource from
>>> the transactional editor, disconnect, updated the instance and
>>> create a SDO Data graph, reconnect and import it back into a
>>> Transactional Editor in order to update its model.
>>>
>>> Does the above scenario make sense?
>>>
>>> If so are there any plans to provide such an interaction between EMF
>>> Transaction components and SDO in the future?
>>>
> thanks again for the support Ed, Happy New Year,
You're welcome. Happy New Year to all!
>
> John
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: SDO and Transaction [message #415704 is a reply to message #415688] |
Mon, 31 December 2007 18:01 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Ed Merks wrote:
> John,
>
> Comments below.
>
>
> John E. Conlon wrote:
>> Hi Ed,
>>
>> See in-line...
>>
>> Ed Merks wrote:
>>> John,
>>>
>>> I'm not sure SDO is needed for such a scenario. An editor can load a
>>> resource from any URI, including HTTP-based ones. In addition, the
>>> URI converter can be specialized to access data that's not accessible
>>> via a real live URL. The URIConverter APIs were enhanced in 2.4 so
>>> that even things like delete are possible;
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 contains a
>>> simple servlet to test save and delete via HTTP.
>>
>> Yes, I saw the previous thread relating to your work on the servlet.
>>
>> Downloaded and took a look at the code for the servlet and the changes
>> in the M4 build. Nice.
>>> At any time you can unload a
>>> resource to discard it's contents and reload it from the backing
>>> store; that's what happens if there's a resource delta in the
>>> workspace via another editor.
>> So when I have multiple clients that have loaded resources from the
>> backing store and any one changes something, the others could be
>> signaled (SomeHow ?) to unload and reload. Right?
> That one reasonable approach. Of course getting a backing store to send
> notifications about changes is something you'd need to hook up. Another
> approach is that clients could poll for changes (as you'd do for CVS).
> With EMF 2.4 a resource keeps track of the timestamp of the resource it
> loads and can check that timestamp against the timestamp in the backing
> store to do optimistic concurrency. There's also generalized support
> for getting and setting attributes of a URI, so it would be possible via
> extensions, for example to lock a resource and find out if it's locked.
>
> Note that the CDO component of EMFT supports true concurrent editing of
> a shared server-based instance, so that might interest you a lot. The
> clients basically make use of EMF's Store APIs so that the EObjects on
> the client side act as thin shadows/wrappers that delegate all data
> access to a master backing store on the server. It's also fully lazy in
> that shadows on the client are created only as the data is accessed.
> When a modification is made, all clients are notified and can update
> their view. It's very cool stuff.
Your right I have been interested in the CDO project and have been
experimenting with it already. I may end up using CDO as my application
requirements dictate a more robust repository solution. But...
for now, CDO's generic editor will not work for me as I have a good bit
of customized functionality in my model specific generated editor.
Perhaps a hybrid approach maybe the way to go with CDO repo in the
backend and model specific generated editors accessing the CDO repo via
the URIConverter/URIHandler(s)?
As a matter of fact what prompted this topic was an emft(CDO) thread
titled: 'Question about CDO - is it possible to disconnect from server?'
Here is what Eike said:
> Lukasz,
>
> CDO is designed to provide Connected Data Objects. It's currently not possible to do with CDO what you ask for. If you open an enhancement request I will have a look at it but that won't be very soon and it may well be that I'll have to reject it for example because it's contrary to the existing requirements. But let's see...
>
> Maybe an SDO implementation (Apache?) is appropriate for you?
>
> Cheers
> /Eike
>
>
>
> Łukasz Olek schrieb:
>> Is it possible to disconnect from the server (be off-line), work on the model, and then synchronize changes when become on-line?
>>
>> If such feature is not available by default - what would require changes to allow it?
>>
>> Or maybe you know other approaches, that would be appropriate?
>>
>> Greetings,
>> Lukasz
kind regards,
John
|
|
|
| Re: SDO and Transaction [message #415705 is a reply to message #415704] |
Tue, 01 January 2008 12:38 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
John,
Comments below.
John E. Conlon wrote:
> Ed Merks wrote:
>> John,
>>
>> Comments below.
>>
>>
>> John E. Conlon wrote:
>>> Hi Ed,
>>>
>>> See in-line...
>>>
>>> Ed Merks wrote:
>>>> John,
>>>>
>>>> I'm not sure SDO is needed for such a scenario. An editor can load
>>>> a resource from any URI, including HTTP-based ones. In addition,
>>>> the URI converter can be specialized to access data that's not
>>>> accessible via a real live URL. The URIConverter APIs were
>>>> enhanced in 2.4 so that even things like delete are possible;
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 contains a
>>>> simple servlet to test save and delete via HTTP.
>>>
>>> Yes, I saw the previous thread relating to your work on the servlet.
>>>
>>> Downloaded and took a look at the code for the servlet and the
>>> changes in the M4 build. Nice.
>>>> At any time you can unload a
>>>> resource to discard it's contents and reload it from the backing
>>>> store; that's what happens if there's a resource delta in the
>>>> workspace via another editor.
>>> So when I have multiple clients that have loaded resources from the
>>> backing store and any one changes something, the others could be
>>> signaled (SomeHow ?) to unload and reload. Right?
>> That one reasonable approach. Of course getting a backing store to
>> send notifications about changes is something you'd need to hook up.
>> Another approach is that clients could poll for changes (as you'd do
>> for CVS). With EMF 2.4 a resource keeps track of the timestamp of
>> the resource it loads and can check that timestamp against the
>> timestamp in the backing store to do optimistic concurrency. There's
>> also generalized support for getting and setting attributes of a URI,
>> so it would be possible via extensions, for example to lock a
>> resource and find out if it's locked.
>>
>> Note that the CDO component of EMFT supports true concurrent editing
>> of a shared server-based instance, so that might interest you a lot.
>> The clients basically make use of EMF's Store APIs so that the
>> EObjects on the client side act as thin shadows/wrappers that
>> delegate all data access to a master backing store on the server.
>> It's also fully lazy in that shadows on the client are created only
>> as the data is accessed. When a modification is made, all clients
>> are notified and can update their view. It's very cool stuff.
> Your right I have been interested in the CDO project and have been
> experimenting with it already. I may end up using CDO as my
> application requirements dictate a more robust repository solution.
> But...
I see your name in the EMFT newsgroup now. I'm usually a bit blind to
names (except for copying the first name at the top of my reply)....
>
> for now, CDO's generic editor will not work for me as I have a good
> bit of customized functionality in my model specific generated editor.
I've not looked closely at how that editor differs from the standard
generated one. I know Eike was looking at generator templates for
generating a CDO editor so I imagine it's customizable in much the same
way and that it uses the identical item providers...
> Perhaps a hybrid approach maybe the way to go with CDO repo in the
> backend and model specific generated editors accessing the CDO repo
> via the URIConverter/URIHandler(s)?
I imagine that would be possible. Certainly Teneo can be hookup up with
just a few changes to configure the resource set.
>
> As a matter of fact what prompted this topic was an emft(CDO) thread
> titled: 'Question about CDO - is it possible to disconnect from server?'
Ah yes, you did want kind of a disconnected model. That would seem to
involve a lot more precaching...
>
> Here is what Eike said:
>
>> Lukasz,
>>
>> CDO is designed to provide Connected Data Objects. It's currently not
>> possible to do with CDO what you ask for. If you open an enhancement
>> request I will have a look at it but that won't be very soon and it
>> may well be that I'll have to reject it for example because it's
>> contrary to the existing requirements. But let's see...
>>
>> Maybe an SDO implementation (Apache?) is appropriate for you?
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Łukasz Olek schrieb:
>>> Is it possible to disconnect from the server (be off-line), work on
>>> the model, and then synchronize changes when become on-line?
>>>
>>> If such feature is not available by default - what would require
>>> changes to allow it?
>>>
>>> Or maybe you know other approaches, that would be appropriate?
>>>
>>> Greetings,
>>> Lukasz
>
Happy New Year.
>
> kind regards,
> John
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: SDO and Transaction [message #415717 is a reply to message #415704] |
Thu, 03 January 2008 11:05 |
|
John,
With respect to the generated editors and the generic CDOEditor I've
taken the time to summarize all the
changes that I applied to the generated editor.
All changes to the generated editor are tagged with a JavaDoc comment
@generated NOT or @ADDED.
If you want to try to investigate my changes I recommend that you
configure these markers as
Java Task Tags in your compiler preferences. Then you can see them all
in the sidebar.
Some changed methods preserve their original with "...Gen" appended just
to keep up with
EMF template evolution. Here are the main changes grouped by topic. Not
all of them are
really necessary. Some of them are merely cosmetic (UI sugar). I hope I
didn't forget important topics:
1) Additional instance fields
a) CDOView view (access to the resource set and all additional CDO
functionality)
b) Object viewerInput (just to make the root of the viewer configurable)
c) CDOEventHandler eventHandler (convenience adapter for CDO events)
2) Configuration of the editing domain
Moved from editor construction to createModel to be able to react on
editor input.
Currently initializeEditingDomain has two tasks: Initialize adapter
factory and
initialize editing domain (including command stack). Better for reuse:
two methods!
3) Special CDOEditorInput delivers
a) CDOView view
b) String resourcePath (optional)
4) Special CDOLabelProvider used in createPages() for
a) Coloring and bolding of dirty and conflict objects
b) Coloring of proxy objects
c) Configurable decoration of label texts with CDOID, CDOState, ...
5) CDOTransaction dirty and commit handling
a) Switch off doSaveAs()
b) Handling of TransactionException (remote or local rollback) in doSave()
c) Calculation of editor's dirty state from CDOView.isDirty()
6) Small changes in editor's init() and dispose() methods
7) Introduction of new CDO actions
a) New sub menu "New Root" for creating new resource contents
(implemented in editor)
b) New action "Bulk Add..." for adding multiple instances at once
(implemented in editor)
c) New action "Import Resource..." (implemented in action bar contributor)
d) New action "Reload" (implemented in action bar contributor)
8) Several methods wrapped so that they can modify UI in the context of
remote updates
a) fireDirtyPropertyChange()
b) refreshViewer()
c) openEditor()
d) closeEditor()
e) RollbackTransactionDialog
9) Static helper methods to
a) find an editor in a page
b) open an editor in a page
c) refresh an editor from outside
I've not looked into the EMF editor templates so far but I doubt that it
will be possible to add all
of the above changes via additional JET includes. Possibly it'd be a bit
easier if more of the code
was moved into a dedicated editor base class.
A general note to the generated editors: If you compare any two of them
right after initial generation
you'll notice that the only difference (except model related namings) is
the ItemProviderAdapterFactory
of the generated model. Even this difference could be eliminated through
the usage of a ComposedAdapterFactory:
Registry registry =
EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
adapterFactory = new ComposedAdapterFactory(registry);
Now you have a nice, reusable component that you can use inpedendant of
your model. All the additional UI work
like coloring, filtering, framework actions, etc. can be used with all
models. Model dependent changes can easily be
applied to the model itself or the generated ItemProviderAdapters. Given
all this I'm not convinced that it is good design
to have lots of editors around that you have to maintain - only because
the EMF generator makes it so easy to have them.
In this sense I even believe that it was a questionable decision to
offer editor generation at all. A functional base class in the
framework could have better prevented from bloating of editor codes.
Flames welcome ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>>
>> Note that the CDO component of EMFT supports true concurrent editing
>> of a shared server-based instance, so that might interest you a lot.
>> The clients basically make use of EMF's Store APIs so that the
>> EObjects on the client side act as thin shadows/wrappers that
>> delegate all data access to a master backing store on the server.
>> It's also fully lazy in that shadows on the client are created only
>> as the data is accessed. When a modification is made, all clients
>> are notified and can update their view. It's very cool stuff.
> Your right I have been interested in the CDO project and have been
> experimenting with it already. I may end up using CDO as my
> application requirements dictate a more robust repository solution.
> But...
>
> for now, CDO's generic editor will not work for me as I have a good
> bit of customized functionality in my model specific generated editor.
> Perhaps a hybrid approach maybe the way to go with CDO repo in the
> backend and model specific generated editors accessing the CDO repo
> via the URIConverter/URIHandler(s)?
>
> As a matter of fact what prompted this topic was an emft(CDO) thread
> titled: 'Question about CDO - is it possible to disconnect from server?'
>
> Here is what Eike said:
>
>> Lukasz,
>>
>> CDO is designed to provide Connected Data Objects. It's currently not
>> possible to do with CDO what you ask for. If you open an enhancement
>> request I will have a look at it but that won't be very soon and it
>> may well be that I'll have to reject it for example because it's
>> contrary to the existing requirements. But let's see...
>>
>> Maybe an SDO implementation (Apache?) is appropriate for you?
>>
>> Cheers
>> /Eike
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: SDO and Transaction [message #415718 is a reply to message #415705] |
Thu, 03 January 2008 11:18 |
|
Ed,
Yes, that's what I wanted to stress by repeating the meaning of the
abbreviation CDO:
John (and Lukasz) asked for means to temporarily disconnect a model from
the remote source (repository) while CDO has mainly been designed for
*connected* data objects.
The feature that makes CDO objects "connected" is the ability to be
asynchronously notified about remote changes. Although this feature can
currently not be switched off this would be a minor change in runtime
configuration (enhancement request appreciated).
Apart from this special feature a CDO session needs "contact" to the
repository only when
1) objects have to be demand loaded (everything could be preloaded as well)
2) transactions are *committed*. Starting a transaction currently also
contacts the server but only to enable the server to optimize database
resource handling (not important for the client, could be switched off).
Working in the transaction (changing, adding or removing objects)
doesn't need server contact.
So it seems as if it would not be that complicated to make CDO
disconnectable, "just" a bit of work ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Ed Merks schrieb:
> John,
>
> Comments below.
>
> John E. Conlon wrote:
>> Ed Merks wrote:
>>> John,
>>>
>>> Comments below.
>>>
>>>
>>> John E. Conlon wrote:
>>>> Hi Ed,
>>>>
>>>> See in-line...
>>>>
>>>> Ed Merks wrote:
>>>>> John,
>>>>>
>>>>> I'm not sure SDO is needed for such a scenario. An editor can
>>>>> load a resource from any URI, including HTTP-based ones. In
>>>>> addition, the URI converter can be specialized to access data
>>>>> that's not accessible via a real live URL. The URIConverter APIs
>>>>> were enhanced in 2.4 so that even things like delete are possible;
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077 contains a
>>>>> simple servlet to test save and delete via HTTP.
>>>>
>>>> Yes, I saw the previous thread relating to your work on the servlet.
>>>>
>>>> Downloaded and took a look at the code for the servlet and the
>>>> changes in the M4 build. Nice.
>>>>> At any time you can unload a
>>>>> resource to discard it's contents and reload it from the backing
>>>>> store; that's what happens if there's a resource delta in the
>>>>> workspace via another editor.
>>>> So when I have multiple clients that have loaded resources from the
>>>> backing store and any one changes something, the others could be
>>>> signaled (SomeHow ?) to unload and reload. Right?
>>> That one reasonable approach. Of course getting a backing store to
>>> send notifications about changes is something you'd need to hook
>>> up. Another approach is that clients could poll for changes (as
>>> you'd do for CVS). With EMF 2.4 a resource keeps track of the
>>> timestamp of the resource it loads and can check that timestamp
>>> against the timestamp in the backing store to do optimistic
>>> concurrency. There's also generalized support for getting and
>>> setting attributes of a URI, so it would be possible via extensions,
>>> for example to lock a resource and find out if it's locked.
>>>
>>> Note that the CDO component of EMFT supports true concurrent editing
>>> of a shared server-based instance, so that might interest you a
>>> lot. The clients basically make use of EMF's Store APIs so that the
>>> EObjects on the client side act as thin shadows/wrappers that
>>> delegate all data access to a master backing store on the server.
>>> It's also fully lazy in that shadows on the client are created only
>>> as the data is accessed. When a modification is made, all clients
>>> are notified and can update their view. It's very cool stuff.
>> Your right I have been interested in the CDO project and have been
>> experimenting with it already. I may end up using CDO as my
>> application requirements dictate a more robust repository solution.
>> But...
> I see your name in the EMFT newsgroup now. I'm usually a bit blind to
> names (except for copying the first name at the top of my reply)....
>>
>> for now, CDO's generic editor will not work for me as I have a good
>> bit of customized functionality in my model specific generated editor.
> I've not looked closely at how that editor differs from the standard
> generated one. I know Eike was looking at generator templates for
> generating a CDO editor so I imagine it's customizable in much the
> same way and that it uses the identical item providers...
>> Perhaps a hybrid approach maybe the way to go with CDO repo in the
>> backend and model specific generated editors accessing the CDO repo
>> via the URIConverter/URIHandler(s)?
> I imagine that would be possible. Certainly Teneo can be hookup up
> with just a few changes to configure the resource set.
>>
>> As a matter of fact what prompted this topic was an emft(CDO) thread
>> titled: 'Question about CDO - is it possible to disconnect from server?'
> Ah yes, you did want kind of a disconnected model. That would seem to
> involve a lot more precaching...
>>
>> Here is what Eike said:
>>
>>> Lukasz,
>>>
>>> CDO is designed to provide Connected Data Objects. It's currently
>>> not possible to do with CDO what you ask for. If you open an
>>> enhancement request I will have a look at it but that won't be very
>>> soon and it may well be that I'll have to reject it for example
>>> because it's contrary to the existing requirements. But let's see...
>>>
>>> Maybe an SDO implementation (Apache?) is appropriate for you?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> Łukasz Olek schrieb:
>>>> Is it possible to disconnect from the server (be off-line), work
>>>> on the model, and then synchronize changes when become on-line?
>>>>
>>>> If such feature is not available by default - what would require
>>>> changes to allow it?
>>>>
>>>> Or maybe you know other approaches, that would be appropriate?
>>>>
>>>> Greetings,
>>>> Lukasz
>>
> Happy New Year.
>>
>> kind regards,
>> John
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: SDO and Transaction [message #415719 is a reply to message #415717] |
Thu, 03 January 2008 11:48 |
Ed Merks
Messages: 33145
Registered: July 2009 |
Senior Member |
|
|
Eike,
We definitely has this type of debate about the generated editor. The
argument in favor of generating it all is that this way is that the user
feels like they have a piece of code entirely visible in their direct
control so they can modify any or all of it rather than having a tiny
extension of a large framework class. The counter argument is certainly
strong as well. Of course given the fact that we generate it makes it
quite easy to change the patterns in arbitrary even non-binary
compatible ways because someone can always omit regenerating their
editor if they don't want to put in the effort of using new improved
patterns...
Eike Stepper wrote:
> John,
>
> With respect to the generated editors and the generic CDOEditor I've
> taken the time to summarize all the
> changes that I applied to the generated editor.
>
> All changes to the generated editor are tagged with a JavaDoc comment
> @generated NOT or @ADDED.
> If you want to try to investigate my changes I recommend that you
> configure these markers as
> Java Task Tags in your compiler preferences. Then you can see them all
> in the sidebar.
> Some changed methods preserve their original with "...Gen" appended
> just to keep up with
> EMF template evolution. Here are the main changes grouped by topic.
> Not all of them are
> really necessary. Some of them are merely cosmetic (UI sugar). I hope
> I didn't forget important topics:
>
> 1) Additional instance fields
> a) CDOView view (access to the resource set and all additional CDO
> functionality)
> b) Object viewerInput (just to make the root of the viewer configurable)
> c) CDOEventHandler eventHandler (convenience adapter for CDO events)
>
> 2) Configuration of the editing domain
> Moved from editor construction to createModel to be able to react on
> editor input.
> Currently initializeEditingDomain has two tasks: Initialize adapter
> factory and
> initialize editing domain (including command stack). Better for reuse:
> two methods!
>
> 3) Special CDOEditorInput delivers
> a) CDOView view
> b) String resourcePath (optional)
>
> 4) Special CDOLabelProvider used in createPages() for
> a) Coloring and bolding of dirty and conflict objects
> b) Coloring of proxy objects
> c) Configurable decoration of label texts with CDOID, CDOState, ...
>
> 5) CDOTransaction dirty and commit handling
> a) Switch off doSaveAs()
> b) Handling of TransactionException (remote or local rollback) in
> doSave()
> c) Calculation of editor's dirty state from CDOView.isDirty()
>
> 6) Small changes in editor's init() and dispose() methods
>
> 7) Introduction of new CDO actions
> a) New sub menu "New Root" for creating new resource contents
> (implemented in editor)
> b) New action "Bulk Add..." for adding multiple instances at once
> (implemented in editor)
> c) New action "Import Resource..." (implemented in action bar
> contributor)
> d) New action "Reload" (implemented in action bar contributor)
>
> 8) Several methods wrapped so that they can modify UI in the context
> of remote updates
> a) fireDirtyPropertyChange()
> b) refreshViewer()
> c) openEditor()
> d) closeEditor()
> e) RollbackTransactionDialog
>
> 9) Static helper methods to
> a) find an editor in a page
> b) open an editor in a page
> c) refresh an editor from outside
>
> I've not looked into the EMF editor templates so far but I doubt that
> it will be possible to add all
> of the above changes via additional JET includes. Possibly it'd be a
> bit easier if more of the code
> was moved into a dedicated editor base class.
>
> A general note to the generated editors: If you compare any two of
> them right after initial generation
> you'll notice that the only difference (except model related namings)
> is the ItemProviderAdapterFactory
> of the generated model. Even this difference could be eliminated
> through the usage of a ComposedAdapterFactory:
>
> Registry registry =
> EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
> adapterFactory = new ComposedAdapterFactory(registry);
>
> Now you have a nice, reusable component that you can use inpedendant
> of your model. All the additional UI work
> like coloring, filtering, framework actions, etc. can be used with all
> models. Model dependent changes can easily be
> applied to the model itself or the generated ItemProviderAdapters.
> Given all this I'm not convinced that it is good design
> to have lots of editors around that you have to maintain - only
> because the EMF generator makes it so easy to have them.
> In this sense I even believe that it was a questionable decision to
> offer editor generation at all. A functional base class in the
> framework could have better prevented from bloating of editor codes.
> Flames welcome ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>>
>>> Note that the CDO component of EMFT supports true concurrent editing
>>> of a shared server-based instance, so that might interest you a
>>> lot. The clients basically make use of EMF's Store APIs so that the
>>> EObjects on the client side act as thin shadows/wrappers that
>>> delegate all data access to a master backing store on the server.
>>> It's also fully lazy in that shadows on the client are created only
>>> as the data is accessed. When a modification is made, all clients
>>> are notified and can update their view. It's very cool stuff.
>> Your right I have been interested in the CDO project and have been
>> experimenting with it already. I may end up using CDO as my
>> application requirements dictate a more robust repository solution.
>> But...
>>
>> for now, CDO's generic editor will not work for me as I have a good
>> bit of customized functionality in my model specific generated
>> editor. Perhaps a hybrid approach maybe the way to go with CDO repo
>> in the backend and model specific generated editors accessing the CDO
>> repo via the URIConverter/URIHandler(s)?
>>
>> As a matter of fact what prompted this topic was an emft(CDO) thread
>> titled: 'Question about CDO - is it possible to disconnect from server?'
>>
>> Here is what Eike said:
>>
>>> Lukasz,
>>>
>>> CDO is designed to provide Connected Data Objects. It's currently
>>> not possible to do with CDO what you ask for. If you open an
>>> enhancement request I will have a look at it but that won't be very
>>> soon and it may well be that I'll have to reject it for example
>>> because it's contrary to the existing requirements. But let's see...
>>>
>>> Maybe an SDO implementation (Apache?) is appropriate for you?
>>>
>>> Cheers
>>> /Eike
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: SDO and Transaction [message #415857 is a reply to message #415717] |
Wed, 09 January 2008 20:32 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
See inline ...
Eike Stepper wrote:
> John,
>
> With respect to the generated editors and the generic CDOEditor I've
> taken the time to summarize all the
> changes that I applied to the generated editor.
>
> All changes to the generated editor are tagged with a JavaDoc comment
> @generated NOT or @ADDED.
> If you want to try to investigate my changes I recommend that you
> configure these markers as
> Java Task Tags in your compiler preferences. Then you can see them all
> in the sidebar.
> Some changed methods preserve their original with "...Gen" appended just
> to keep up with
> EMF template evolution. Here are the main changes grouped by topic. Not
> all of them are
> really necessary. Some of them are merely cosmetic (UI sugar). I hope I
> didn't forget important topics:
>
> 1) Additional instance fields
> a) CDOView view (access to the resource set and all additional CDO
> functionality)
> b) Object viewerInput (just to make the root of the viewer configurable)
> c) CDOEventHandler eventHandler (convenience adapter for CDO events)
>
> 2) Configuration of the editing domain
> Moved from editor construction to createModel to be able to react on
> editor input.
> Currently initializeEditingDomain has two tasks: Initialize adapter
> factory and
> initialize editing domain (including command stack). Better for reuse:
> two methods!
>
> 3) Special CDOEditorInput delivers
> a) CDOView view
> b) String resourcePath (optional)
>
> 4) Special CDOLabelProvider used in createPages() for
> a) Coloring and bolding of dirty and conflict objects
> b) Coloring of proxy objects
> c) Configurable decoration of label texts with CDOID, CDOState, ...
>
> 5) CDOTransaction dirty and commit handling
> a) Switch off doSaveAs()
> b) Handling of TransactionException (remote or local rollback) in doSave()
> c) Calculation of editor's dirty state from CDOView.isDirty()
>
> 6) Small changes in editor's init() and dispose() methods
>
> 7) Introduction of new CDO actions
> a) New sub menu "New Root" for creating new resource contents
> (implemented in editor)
> b) New action "Bulk Add..." for adding multiple instances at once
> (implemented in editor)
> c) New action "Import Resource..." (implemented in action bar contributor)
> d) New action "Reload" (implemented in action bar contributor)
>
> 8) Several methods wrapped so that they can modify UI in the context of
> remote updates
> a) fireDirtyPropertyChange()
> b) refreshViewer()
> c) openEditor()
> d) closeEditor()
> e) RollbackTransactionDialog
>
> 9) Static helper methods to
> a) find an editor in a page
> b) open an editor in a page
> c) refresh an editor from outside
Thank you for summarizing the changes.
>
> I've not looked into the EMF editor templates so far but I doubt that it
> will be possible to add all
> of the above changes via additional JET includes. Possibly it'd be a bit
> easier if more of the code
> was moved into a dedicated editor base class.
Makes sense.
>
> A general note to the generated editors: If you compare any two of them
> right after initial generation
> you'll notice that the only difference (except model related namings) is
> the ItemProviderAdapterFactory
> of the generated model. Even this difference could be eliminated through
> the usage of a ComposedAdapterFactory:
>
> Registry registry =
> EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
> adapterFactory = new ComposedAdapterFactory(registry);
>
> Now you have a nice, reusable component that you can use inpedendant of
> your model. All the additional UI work
> like coloring, filtering, framework actions, etc. can be used with all
> models. Model dependent changes can easily be
> applied to the model itself or the generated ItemProviderAdapters. Given
> all this I'm not convinced that it is good design
> to have lots of editors around that you have to maintain - only because
> the EMF generator makes it so easy to have them.
This is where I am now too many editors to maintain:-( so I am looking
for alternatives.
A common heterogeneous model editor makes a lot of sense, provided I
could navigate the model instance in a way appropriate to the model.
Would want to have customized Table Viewers and Forms. Perhaps those
could be extension points to a generic editor?
I am watching the work the EMF data binding efforts at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625
which I think will move us closer to that kind of generic editor?
kind regards,
John
> In this sense I even believe that it was a questionable decision to
> offer editor generation at all. A functional base class in the
> framework could have better prevented from bloating of editor codes.
> Flames welcome ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>>
>>> Note that the CDO component of EMFT supports true concurrent editing
>>> of a shared server-based instance, so that might interest you a lot.
>>> The clients basically make use of EMF's Store APIs so that the
>>> EObjects on the client side act as thin shadows/wrappers that
>>> delegate all data access to a master backing store on the server.
>>> It's also fully lazy in that shadows on the client are created only
>>> as the data is accessed. When a modification is made, all clients
>>> are notified and can update their view. It's very cool stuff.
>> Your right I have been interested in the CDO project and have been
>> experimenting with it already. I may end up using CDO as my
>> application requirements dictate a more robust repository solution.
>> But...
>>
>> for now, CDO's generic editor will not work for me as I have a good
>> bit of customized functionality in my model specific generated editor.
>> Perhaps a hybrid approach maybe the way to go with CDO repo in the
>> backend and model specific generated editors accessing the CDO repo
>> via the URIConverter/URIHandler(s)?
>>
>> As a matter of fact what prompted this topic was an emft(CDO) thread
>> titled: 'Question about CDO - is it possible to disconnect from server?'
>>
>> Here is what Eike said:
>>
>>> Lukasz,
>>>
>>> CDO is designed to provide Connected Data Objects. It's currently not
>>> possible to do with CDO what you ask for. If you open an enhancement
>>> request I will have a look at it but that won't be very soon and it
>>> may well be that I'll have to reject it for example because it's
>>> contrary to the existing requirements. But let's see...
>>>
>>> Maybe an SDO implementation (Apache?) is appropriate for you?
>>>
>>> Cheers
>>> /Eike
>>>
|
|
|
Goto Forum:
Current Time: Sun May 05 08:07:49 GMT 2024
Powered by FUDForum. Page generated in 0.03276 seconds |
] 
Search
Help
Register
Login
Home
