Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMFStore] access to EditingDomain in EMFStore
[EMFStore] access to EditingDomain in EMFStore [message #1126710] Sat, 05 October 2013 22:19 Go to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 132
Registered: July 2009
Senior Member
I have an EMF-based RCP application that looks like a good fit for
EMFStore. The offline-by-design capability is particularly attractive
since my application times sporting event and needs to be resilient even
over an unreliable network.

I've read your paper, looked over the source code and have built
prototypes to understand how to EMFStore works and to explore the
external API. It's a very impressive piece of work!

I'm starting to integrate EMFStore with the application. The core of my
application uses code patterns generated from EMF's 'edit' and 'editor'
code generators, which leverage the EditingDomain's command stack for
executing commands, providing do/undo support and determining whether a
model instance is dirty.

EMFStore's own persistent store and ModelElements seems to be a very
different persistence model than the Resource-based XMI and CDO
persistence engines. And I'm guessing that it's use of the internal
EditingDomain is different as well.

What recommendations do you have surfacing do/undo and determining
whether model instance is dirty? Should I use the EditingDomain
available in the ESWorkspaceImpl?

Scott
Re: [EMFStore] access to EditingDomain in EMFStore [message #1129068 is a reply to message #1126710] Tue, 08 October 2013 08:53 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 225
Registered: July 2009
Senior Member
Hi Scott,

thank you for your compliments! ;)
>
> EMFStore's own persistent store and ModelElements seems to be a very
> different persistence model than the Resource-based XMI and CDO
> persistence engines. And I'm guessing that it's use of the internal
> EditingDomain is different as well.
>
> What recommendations do you have surfacing do/undo and determining
> whether model instance is dirty? Should I use the EditingDomain
> available in the ESWorkspaceImpl?
Yes, you should use this EditingDomain and run your commands on the
command stack of this editing domain. The editing domain will be
attached to any of you domain objects and can be retrieved with
AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
undo/redo capabilities of the command stack as usual.
To avoid manually implementing undo for custom commands (e.g. non EMF
Commands), there is a way to use the recorded changes of EMFStore to
implement undo, but it requires replacing the default EMFStore command
stack. There are EMFStore users that are using EMFStore in this way.
With EMFStore 1.1 it will be possible to have one command stack per
project, in case you need that.
To determine if there are pending changes on a project you can use
hasUncomittedChanges(), which will return true if you changed something
locally without committing the changes to a server.
Let me know if I can provide more help!

Cheers,
Maximilian

>
> Scott
>


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Re: [EMFStore] access to EditingDomain in EMFStore [message #1129646 is a reply to message #1129068] Tue, 08 October 2013 21:16 Go to previous messageGo to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 132
Registered: July 2009
Senior Member
Maximilian,

The compliments are well deserved.

I have specialized the standard EMF CommandStack to allow for listening
on dirty state changes. If I understand your comment below, in EMFStore
1.1 I'll be able to replace the CommandStack with my own specialized
version. Do I have that right?

I use this MonitoredCommandStack as a trigger for an auto-save feature
for standard EMF XMI resources. With EMFStore there seems to be an
auto-save feature already built-in, but I'm not sure how I should be
using it.

Scott

On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
> Hi Scott,
>
> thank you for your compliments! ;)
>>
>> EMFStore's own persistent store and ModelElements seems to be a very
>> different persistence model than the Resource-based XMI and CDO
>> persistence engines. And I'm guessing that it's use of the internal
>> EditingDomain is different as well.
>>
>> What recommendations do you have surfacing do/undo and determining
>> whether model instance is dirty? Should I use the EditingDomain
>> available in the ESWorkspaceImpl?
> Yes, you should use this EditingDomain and run your commands on the
> command stack of this editing domain. The editing domain will be
> attached to any of you domain objects and can be retrieved with
> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
> undo/redo capabilities of the command stack as usual.
> To avoid manually implementing undo for custom commands (e.g. non EMF
> Commands), there is a way to use the recorded changes of EMFStore to
> implement undo, but it requires replacing the default EMFStore command
> stack. There are EMFStore users that are using EMFStore in this way.
> With EMFStore 1.1 it will be possible to have one command stack per
> project, in case you need that.
> To determine if there are pending changes on a project you can use
> hasUncomittedChanges(), which will return true if you changed something
> locally without committing the changes to a server.
> Let me know if I can provide more help!
>
> Cheers,
> Maximilian
>
>>
>> Scott
>>
>
>
Re: [EMFStore] access to EditingDomain in EMFStore [message #1130233 is a reply to message #1129646] Wed, 09 October 2013 10:44 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 225
Registered: July 2009
Senior Member
Hi Scott,

by implementing the interface ESEditingDomainProvider and registering it
via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
point in the org.eclipse.emf.emfstore.client plugin, you can already
replace the editing domain including its command stack. Please note that
your command stack must implement EMFStoreCommandStack, which is
currently an internal interface unfortunately, see this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
An example for replacing the editing domain and command stack is the
plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
editing domain with a transaction editing domain and a transactional
command stack.
The auto-save feature is not exposed in the (external) API and we chose
to remove it also internally since it can cause performance problems for
larger models. (It is off by default.)
Hope this helps!

Cheers,
Maximilian

Am 08.10.2013 23:16, schrieb Scott Dybiec:
> Maximilian,
>
> The compliments are well deserved.
>
> I have specialized the standard EMF CommandStack to allow for listening
> on dirty state changes. If I understand your comment below, in EMFStore
> 1.1 I'll be able to replace the CommandStack with my own specialized
> version. Do I have that right?
>
> I use this MonitoredCommandStack as a trigger for an auto-save feature
> for standard EMF XMI resources. With EMFStore there seems to be an
> auto-save feature already built-in, but I'm not sure how I should be
> using it.
>
> Scott
>
> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>> Hi Scott,
>>
>> thank you for your compliments! ;)
>>>
>>> EMFStore's own persistent store and ModelElements seems to be a very
>>> different persistence model than the Resource-based XMI and CDO
>>> persistence engines. And I'm guessing that it's use of the internal
>>> EditingDomain is different as well.
>>>
>>> What recommendations do you have surfacing do/undo and determining
>>> whether model instance is dirty? Should I use the EditingDomain
>>> available in the ESWorkspaceImpl?
>> Yes, you should use this EditingDomain and run your commands on the
>> command stack of this editing domain. The editing domain will be
>> attached to any of you domain objects and can be retrieved with
>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>> undo/redo capabilities of the command stack as usual.
>> To avoid manually implementing undo for custom commands (e.g. non EMF
>> Commands), there is a way to use the recorded changes of EMFStore to
>> implement undo, but it requires replacing the default EMFStore command
>> stack. There are EMFStore users that are using EMFStore in this way.
>> With EMFStore 1.1 it will be possible to have one command stack per
>> project, in case you need that.
>> To determine if there are pending changes on a project you can use
>> hasUncomittedChanges(), which will return true if you changed something
>> locally without committing the changes to a server.
>> Let me know if I can provide more help!
>>
>> Cheers,
>> Maximilian
>>
>>>
>>> Scott
>>>
>>
>>
>


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Re: [EMFStore] access to EditingDomain in EMFStore [message #1137299 is a reply to message #1130233] Mon, 14 October 2013 11:45 Go to previous messageGo to next message
Scott Dybiec is currently offline Scott DybiecFriend
Messages: 132
Registered: July 2009
Senior Member
Thanks, Maximilian. That worked.

I also have a related question.

I'd like to be able to store and later find specific model elements
stored in EMFStore by a name or tag that my application generates. Today
my application stores EMF files in a workspace project. If I were to add
these as model elements to EMFStore, then I think the only way to find
them again is by the EMFStore-assigned model element ID.

If assigning an application-defined name is not possible, then is it OK
to use the ResourceSet within the EMFStore EditingDomain to create EMF
Resources? Will proxies be resolved between these newly created
resources and those managed as model elements within EMFStore?

$cott

On 10/9/2013 6:44 AM, Maximilian Koegel wrote:
> Hi Scott,
>
> by implementing the interface ESEditingDomainProvider and registering it
> via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
> point in the org.eclipse.emf.emfstore.client plugin, you can already
> replace the editing domain including its command stack. Please note that
> your command stack must implement EMFStoreCommandStack, which is
> currently an internal interface unfortunately, see this bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
> An example for replacing the editing domain and command stack is the
> plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
> editing domain with a transaction editing domain and a transactional
> command stack.
> The auto-save feature is not exposed in the (external) API and we chose
> to remove it also internally since it can cause performance problems for
> larger models. (It is off by default.)
> Hope this helps!
>
> Cheers,
> Maximilian
>
> Am 08.10.2013 23:16, schrieb Scott Dybiec:
>> Maximilian,
>>
>> The compliments are well deserved.
>>
>> I have specialized the standard EMF CommandStack to allow for listening
>> on dirty state changes. If I understand your comment below, in EMFStore
>> 1.1 I'll be able to replace the CommandStack with my own specialized
>> version. Do I have that right?
>>
>> I use this MonitoredCommandStack as a trigger for an auto-save feature
>> for standard EMF XMI resources. With EMFStore there seems to be an
>> auto-save feature already built-in, but I'm not sure how I should be
>> using it.
>>
>> Scott
>>
>> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>>> Hi Scott,
>>>
>>> thank you for your compliments! ;)
>>>>
>>>> EMFStore's own persistent store and ModelElements seems to be a very
>>>> different persistence model than the Resource-based XMI and CDO
>>>> persistence engines. And I'm guessing that it's use of the internal
>>>> EditingDomain is different as well.
>>>>
>>>> What recommendations do you have surfacing do/undo and determining
>>>> whether model instance is dirty? Should I use the EditingDomain
>>>> available in the ESWorkspaceImpl?
>>> Yes, you should use this EditingDomain and run your commands on the
>>> command stack of this editing domain. The editing domain will be
>>> attached to any of you domain objects and can be retrieved with
>>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>>> undo/redo capabilities of the command stack as usual.
>>> To avoid manually implementing undo for custom commands (e.g. non EMF
>>> Commands), there is a way to use the recorded changes of EMFStore to
>>> implement undo, but it requires replacing the default EMFStore command
>>> stack. There are EMFStore users that are using EMFStore in this way.
>>> With EMFStore 1.1 it will be possible to have one command stack per
>>> project, in case you need that.
>>> To determine if there are pending changes on a project you can use
>>> hasUncomittedChanges(), which will return true if you changed something
>>> locally without committing the changes to a server.
>>> Let me know if I can provide more help!
>>>
>>> Cheers,
>>> Maximilian
>>>
>>>>
>>>> Scott
>>>>
>>>
>>>
>>
>
>
Re: [EMFStore] access to EditingDomain in EMFStore [message #1137735 is a reply to message #1137299] Mon, 14 October 2013 17:58 Go to previous message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 225
Registered: July 2009
Senior Member
Hi Scott,

I am not sure if fully understand what you want to do but I will try to
provide an answer...;)
You can influence the IDs (they are essentially Strings) assigned to
model elements in two ways. For both ways it is essential that the IDs
you assign are really unique within a project, otherwise behavior is
unspecified.
First you can register an ESModelElementIdGenerator at the extension
point "org.eclipse.emf.emfstore.common.model.modelelementIdGenerator".
Thereby you can assign IDs to newly created elements.
Second you can pre-assign an ID to a selected EObject BEFORE adding it
to a project (or the containment tree of a project). This is currently
internal API only so you need to cast ESLocalProject to
ESLocalProjectImpl and call the method toInternalAPI(). It will return a
ProjectSpace which is an internal API type that gives you full access to
all EMFStore internals. On ProjectSpace you can call
getProject().allocateModelElementIds() to pre-allocate IDs for new EObjects.
BTW: This is a common pattern to get to the internal API of a class X.
Cast to XImpl and call toInternalAPI(). We intend to add more methods to
the API over time, so let me know if you need something of the internal API.
Hope this works for you!

Cheers,
Maximilian

Am 14.10.2013 13:45, schrieb scott@xxxxxxxx:
> Thanks, Maximilian. That worked.
>
> I also have a related question.
>
> I'd like to be able to store and later find specific model elements
> stored in EMFStore by a name or tag that my application generates. Today
> my application stores EMF files in a workspace project. If I were to add
> these as model elements to EMFStore, then I think the only way to find
> them again is by the EMFStore-assigned model element ID.
>
> If assigning an application-defined name is not possible, then is it OK
> to use the ResourceSet within the EMFStore EditingDomain to create EMF
> Resources? Will proxies be resolved between these newly created
> resources and those managed as model elements within EMFStore?
>
> $cott
>
> On 10/9/2013 6:44 AM, Maximilian Koegel wrote:
>> Hi Scott,
>>
>> by implementing the interface ESEditingDomainProvider and registering it
>> via the org.eclipse.emf.emfstore.client.editingDomainProvider extension
>> point in the org.eclipse.emf.emfstore.client plugin, you can already
>> replace the editing domain including its command stack. Please note that
>> your command stack must implement EMFStoreCommandStack, which is
>> currently an internal interface unfortunately, see this bug:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419009
>> An example for replacing the editing domain and command stack is the
>> plugin org.eclipse.emf.emfstore.client.transaction, it replaced the
>> editing domain with a transaction editing domain and a transactional
>> command stack.
>> The auto-save feature is not exposed in the (external) API and we chose
>> to remove it also internally since it can cause performance problems for
>> larger models. (It is off by default.)
>> Hope this helps!
>>
>> Cheers,
>> Maximilian
>>
>> Am 08.10.2013 23:16, schrieb Scott Dybiec:
>>> Maximilian,
>>>
>>> The compliments are well deserved.
>>>
>>> I have specialized the standard EMF CommandStack to allow for listening
>>> on dirty state changes. If I understand your comment below, in EMFStore
>>> 1.1 I'll be able to replace the CommandStack with my own specialized
>>> version. Do I have that right?
>>>
>>> I use this MonitoredCommandStack as a trigger for an auto-save feature
>>> for standard EMF XMI resources. With EMFStore there seems to be an
>>> auto-save feature already built-in, but I'm not sure how I should be
>>> using it.
>>>
>>> Scott
>>>
>>> On 10/8/2013 4:53 AM, Maximilian Koegel wrote:
>>>> Hi Scott,
>>>>
>>>> thank you for your compliments! ;)
>>>>>
>>>>> EMFStore's own persistent store and ModelElements seems to be a very
>>>>> different persistence model than the Resource-based XMI and CDO
>>>>> persistence engines. And I'm guessing that it's use of the internal
>>>>> EditingDomain is different as well.
>>>>>
>>>>> What recommendations do you have surfacing do/undo and determining
>>>>> whether model instance is dirty? Should I use the EditingDomain
>>>>> available in the ESWorkspaceImpl?
>>>> Yes, you should use this EditingDomain and run your commands on the
>>>> command stack of this editing domain. The editing domain will be
>>>> attached to any of you domain objects and can be retrieved with
>>>> AdapterFactoryEditingDomain.getEditingDomainFor(). You can use the
>>>> undo/redo capabilities of the command stack as usual.
>>>> To avoid manually implementing undo for custom commands (e.g. non EMF
>>>> Commands), there is a way to use the recorded changes of EMFStore to
>>>> implement undo, but it requires replacing the default EMFStore command
>>>> stack. There are EMFStore users that are using EMFStore in this way.
>>>> With EMFStore 1.1 it will be possible to have one command stack per
>>>> project, in case you need that.
>>>> To determine if there are pending changes on a project you can use
>>>> hasUncomittedChanges(), which will return true if you changed something
>>>> locally without committing the changes to a server.
>>>> Let me know if I can provide more help!
>>>>
>>>> Cheers,
>>>> Maximilian
>>>>
>>>>>
>>>>> Scott
>>>>>
>>>>
>>>>
>>>
>>
>>
>


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Previous Topic:[Teneo] (rewritten question): Resource is empty on read, despite DB populated correctly
Next Topic:[CDO] Code Review for a faster Horizontal Mapping
Goto Forum:
  


Current Time: Thu Dec 18 20:15:48 GMT 2014

Powered by FUDForum. Page generated in 0.01958 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software