Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMFStore][EMFClient] Using the EMFStore for simple storage
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1243530 is a reply to message #1243330] |
Tue, 11 February 2014 05:04   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
If you're fed up with your database, do you need a database at all?
EMF files are normally ASCII so can be versioned using a CM such as GIT.
The default JVM size can handle about 1,000,000 objects, so your
400x1000 could fit in memory directly without increasing the JVM.
Regards
Ed Willink
On 10/02/2014 21:19, Marina Knieling wrote:
> Hey guys,
>
> as I'm recently fed up with my database implementation and because I'm
> using parts of ECP already I'm looking into EMFStore now.
>
> In general I only want to persist some EMF models and maybe use the
> versioning feature. The application will only run on the user's local
> computer and the user will be the only one who is modifying the
> models, so I won't need the real repository functionality (for now,
> might change later).
>
> Is it possible to use EMFStore without server or do I have to start a
> local server (which I could hide from the user and start when the
> application starts - and stop when the application is shut down)?.
>
> Furthermore, my models aren't based on any project like stuff, but I
> understand that I need an ESLocalProject in order to save my EMF
> models to the EMFStore. Is it ok to simply create an ESLocalProject,
> add my model elements and hide the project stuff from the user,
> performing all the necessary tasks in the background? The reason for
> that is that I don't want to confront my users with terms and
> processes that aren't known to them (they rather have a musical
> background than a technical).
>
> Another question I have is related to the performance. IIRC I have
> read somewhere that the EMFStore loads all - local? - projects into
> memory. My model has two connected *-to-many references where _many_
> might easily be 500 or more.
>
> Example:
> A has many B and B has many C where B can be up to 1000 and C can be
> up to almost 400.
>
> Are there any problems I might face when loading a project of this
> scope into my application and what can I do to improve performance?
>
> Thanks in advance for any hints and help.
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1243822 is a reply to message #1243330] |
Tue, 11 February 2014 13:48 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi,
comments below...
Am 10.02.2014 22:19, schrieb Marina Knieling:
> Hey guys,
>
> as I'm recently fed up with my database implementation and because I'm
> using parts of ECP already I'm looking into EMFStore now.
>
> In general I only want to persist some EMF models and maybe use the
> versioning feature. The application will only run on the user's local
> computer and the user will be the only one who is modifying the models,
> so I won't need the real repository functionality (for now, might change
> later).
>
> Is it possible to use EMFStore without server or do I have to start a
> local server (which I could hide from the user and start when the
> application starts - and stop when the application is shut down)?.
Absolutly! In this case, you might not even need a server at all, you
could just use the client persistence of EMFStore. In the default
implementation, it will just store in XMI. It therefore provides you
with an abstraction of files, so you do not have to take care about
files at all. The persistence is interchangable, so you can adapt this
later on.
If you want to use some local versioning, you can also start a local
server. The ECP demo application allows to do that manually (right click
on the local emfstore in the repository view). The bundel *localemfstore
contains the corresponding code and should provide a template how you
can embbed this into your applications lifecycle without manual
operations by the user.
>
> Furthermore, my models aren't based on any project like stuff, but I
> understand that I need an ESLocalProject in order to save my EMF models
> to the EMFStore. Is it ok to simply create an ESLocalProject, add my
> model elements and hide the project stuff from the user, performing all
> the necessary tasks in the background? The reason for that is that I
> don't want to confront my users with terms and processes that aren't
> known to them (they rather have a musical background than a technical).
Absolutly, many projects implement there own custom view to replace the
model explorer at some point in time, especially, if the application
does not support the concept of a "project". For this custom view, you
can reuse the content provider of ECP to keep the adaptations done by
ECP (it is used in the model explorer) or use the default one.
>
> Another question I have is related to the performance. IIRC I have read
> somewhere that the EMFStore loads all - local? - projects into memory.
> My model has two connected *-to-many references where _many_ might
> easily be 500 or more.
If you use the default persistence of EMFStore on the client side, it
will behave like you would store the data in an XMI file. This will
sooner or later effect, that all the data is in memory. It is possible
to improve this by using another persistence on the client, but not "for
free". As Ed mentioned, the performance of XMI might be enough for you.
I recommend to create a test model, which is let's say 10 times bigger
than your typical use case and test whether memory consumption is an
issue for you.
Best regards
Jonas
>
> Example:
> A has many B and B has many C where B can be up to 1000 and C can be up
> to almost 400.
>
> Are there any problems I might face when loading a project of this scope
> into my application and what can I do to improve performance?
>
> Thanks in advance for any hints and help.
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1243825 is a reply to message #1243530] |
Tue, 11 February 2014 13:51 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi,
EMFStore (and CDO) are no databases. They add an additional layer with
features such as versioning, collaboration, etc. Both frameworks allow
to use different technologies (e.g. a database) for storage.
The number of objects fitting in memory depends much on their size and
complexity. Although 1.000.000 is typically a good estimation.
Cheers
Jonas
Am 11.02.2014 06:04, schrieb Ed Willink:
> Hi
>
> If you're fed up with your database, do you need a database at all?
>
> EMF files are normally ASCII so can be versioned using a CM such as GIT.
>
> The default JVM size can handle about 1,000,000 objects, so your
> 400x1000 could fit in memory directly without increasing the JVM.
>
> Regards
>
> Ed Willink
>
>
> On 10/02/2014 21:19, Marina Knieling wrote:
>> Hey guys,
>>
>> as I'm recently fed up with my database implementation and because I'm
>> using parts of ECP already I'm looking into EMFStore now.
>>
>> In general I only want to persist some EMF models and maybe use the
>> versioning feature. The application will only run on the user's local
>> computer and the user will be the only one who is modifying the
>> models, so I won't need the real repository functionality (for now,
>> might change later).
>>
>> Is it possible to use EMFStore without server or do I have to start a
>> local server (which I could hide from the user and start when the
>> application starts - and stop when the application is shut down)?.
>>
>> Furthermore, my models aren't based on any project like stuff, but I
>> understand that I need an ESLocalProject in order to save my EMF
>> models to the EMFStore. Is it ok to simply create an ESLocalProject,
>> add my model elements and hide the project stuff from the user,
>> performing all the necessary tasks in the background? The reason for
>> that is that I don't want to confront my users with terms and
>> processes that aren't known to them (they rather have a musical
>> background than a technical).
>>
>> Another question I have is related to the performance. IIRC I have
>> read somewhere that the EMFStore loads all - local? - projects into
>> memory. My model has two connected *-to-many references where _many_
>> might easily be 500 or more.
>>
>> Example:
>> A has many B and B has many C where B can be up to 1000 and C can be
>> up to almost 400.
>>
>> Are there any problems I might face when loading a project of this
>> scope into my application and what can I do to improve performance?
>>
>> Thanks in advance for any hints and help.
>
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1248584 is a reply to message #1243822] |
Mon, 17 February 2014 12:28 |
Marina Knieling
Messages: 83
Registered: February 2013 |
Member |
|
|
Hi Jonas, my saviour
thanks for your quick and detailed (as always) reply. That was the
answer I was hoping for.
More comments / questions below...
Am 11.02.2014 14:48, schrieb Jonas Helming:
> Hi,
>
> comments below...
>
> Am 10.02.2014 22:19, schrieb Marina Knieling:
>> Hey guys,
>>
>> as I'm recently fed up with my database implementation and because I'm
>> using parts of ECP already I'm looking into EMFStore now.
>>
>> In general I only want to persist some EMF models and maybe use the
>> versioning feature. The application will only run on the user's local
>> computer and the user will be the only one who is modifying the models,
>> so I won't need the real repository functionality (for now, might change
>> later).
>>
>> Is it possible to use EMFStore without server or do I have to start a
>> local server (which I could hide from the user and start when the
>> application starts - and stop when the application is shut down)?.
> Absolutly! In this case, you might not even need a server at all, you
> could just use the client persistence of EMFStore. In the default
> implementation, it will just store in XMI. It therefore provides you
> with an abstraction of files, so you do not have to take care about
> files at all. The persistence is interchangable, so you can adapt this
> later on.
Which bundles will I need in order to get this up and running? For the
ECP parts I only use the editor and I already have a customized version
of the ECPE4Editor and my own E4ModelElementOpener.
I found an *ecp.emfstore bundle and then the pure emfstore.common and
emfstore.client and emfstore.server bundles. It seems like ecp.emfstore
is the data provider that is only needed if I also use the ECPProject
concept (which I don't, got rid of that already).
There is an EMFStoreResource in the emfstore.common bundle and a
ClientXMIResourceSetProvider in the emfstore.client bundle which seems
to use the "simple" emf ResourceSet in contrast to the before mentioned
EMFStoreResource. What's the difference between them and is this even
the correct spot to start (i.e. do I have to do the persistence the EMF
way) or do I miss some API from the EMFStore?
> If you want to use some local versioning, you can also start a local
> server. The ECP demo application allows to do that manually (right click
> on the local emfstore in the repository view). The bundel *localemfstore
> contains the corresponding code and should provide a template how you
> can embbed this into your applications lifecycle without manual
> operations by the user.
Looked into that and looks like it's only one call to
EMFStoreController.runAsNewThread().
Thanks again for your help and have a nice day
Marina
>>
>> Furthermore, my models aren't based on any project like stuff, but I
>> understand that I need an ESLocalProject in order to save my EMF models
>> to the EMFStore. Is it ok to simply create an ESLocalProject, add my
>> model elements and hide the project stuff from the user, performing all
>> the necessary tasks in the background? The reason for that is that I
>> don't want to confront my users with terms and processes that aren't
>> known to them (they rather have a musical background than a technical).
> Absolutly, many projects implement there own custom view to replace the
> model explorer at some point in time, especially, if the application
> does not support the concept of a "project". For this custom view, you
> can reuse the content provider of ECP to keep the adaptations done by
> ECP (it is used in the model explorer) or use the default one.
>>
>> Another question I have is related to the performance. IIRC I have read
>> somewhere that the EMFStore loads all - local? - projects into memory.
>> My model has two connected *-to-many references where _many_ might
>> easily be 500 or more.
> If you use the default persistence of EMFStore on the client side, it
> will behave like you would store the data in an XMI file. This will
> sooner or later effect, that all the data is in memory. It is possible
> to improve this by using another persistence on the client, but not "for
> free". As Ed mentioned, the performance of XMI might be enough for you.
> I recommend to create a test model, which is let's say 10 times bigger
> than your typical use case and test whether memory consumption is an
> issue for you.
>
> Best regards
>
> Jonas
>
>>
>> Example:
>> A has many B and B has many C where B can be up to 1000 and C can be up
>> to almost 400.
>>
>> Are there any problems I might face when loading a project of this scope
>> into my application and what can I do to improve performance?
>>
>> Thanks in advance for any hints and help.
>
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1249424 is a reply to message #1248584] |
Tue, 18 February 2014 08:40 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi Marina,
Am 17.02.2014 13:28, schrieb Marina Knieling:
>
> Hi Jonas, my saviour
>
> thanks for your quick and detailed (as always) reply. That was the
> answer I was hoping for.
you are welcome! :-)
>
> More comments / questions below...
>
> Am 11.02.2014 14:48, schrieb Jonas Helming:
>> Hi,
>>
>> comments below...
>>
>> Am 10.02.2014 22:19, schrieb Marina Knieling:
>>> Hey guys,
>>>
>>> as I'm recently fed up with my database implementation and because I'm
>>> using parts of ECP already I'm looking into EMFStore now.
>>>
>>> In general I only want to persist some EMF models and maybe use the
>>> versioning feature. The application will only run on the user's local
>>> computer and the user will be the only one who is modifying the models,
>>> so I won't need the real repository functionality (for now, might change
>>> later).
>>>
>>> Is it possible to use EMFStore without server or do I have to start a
>>> local server (which I could hide from the user and start when the
>>> application starts - and stop when the application is shut down)?.
>> Absolutly! In this case, you might not even need a server at all, you
>> could just use the client persistence of EMFStore. In the default
>> implementation, it will just store in XMI. It therefore provides you
>> with an abstraction of files, so you do not have to take care about
>> files at all. The persistence is interchangable, so you can adapt this
>> later on.
>
> Which bundles will I need in order to get this up and running? For the
> ECP parts I only use the editor and I already have a customized version
> of the ECPE4Editor and my own E4ModelElementOpener.
>
> I found an *ecp.emfstore bundle and then the pure emfstore.common and
> emfstore.client and emfstore.server bundles. It seems like ecp.emfstore
> is the data provider that is only needed if I also use the ECPProject
> concept (which I don't, got rid of that already).
>
> There is an EMFStoreResource in the emfstore.common bundle and a
> ClientXMIResourceSetProvider in the emfstore.client bundle which seems
> to use the "simple" emf ResourceSet in contrast to the before mentioned
> EMFStoreResource. What's the difference between them and is this even
> the correct spot to start (i.e. do I have to do the persistence the EMF
> way) or do I miss some API from the EMFStore?
There are two ways of doing that. You can either use the API of ECP,
which abstracts the functionality of the underlying data provider. This
keeps the data provider interchangable, you could even implement your
own data provider later on. This API is provided by the *.core bundle of
ECP. Additionally the corresponding bundles of at least one data
provider (e.g. EMFStore) must be running, but you do not access their
API (they do not provide any)
The second choice is to directly use the EMFStore API, have you had a
look at this documentation:
http://eclipse.org/emfstore/documentation.html
In both cases you need to use the concept of a project, even though you
hide it from your user. Both, ECP and EMFStore, require a project as a
"root container". In fact the ECPProject is pointing to an EMFStore
project, in case EMFStore is the data provider.
I would generally prefer the first choice, as it keeps your backend
interchangeable.
Best Regards
Jonas
>
>> If you want to use some local versioning, you can also start a local
>> server. The ECP demo application allows to do that manually (right click
>> on the local emfstore in the repository view). The bundel *localemfstore
>> contains the corresponding code and should provide a template how you
>> can embbed this into your applications lifecycle without manual
>> operations by the user.
>
> Looked into that and looks like it's only one call to
> EMFStoreController.runAsNewThread().
>
> Thanks again for your help and have a nice day
>
> Marina
>
>>>
>>> Furthermore, my models aren't based on any project like stuff, but I
>>> understand that I need an ESLocalProject in order to save my EMF models
>>> to the EMFStore. Is it ok to simply create an ESLocalProject, add my
>>> model elements and hide the project stuff from the user, performing all
>>> the necessary tasks in the background? The reason for that is that I
>>> don't want to confront my users with terms and processes that aren't
>>> known to them (they rather have a musical background than a technical).
>> Absolutly, many projects implement there own custom view to replace the
>> model explorer at some point in time, especially, if the application
>> does not support the concept of a "project". For this custom view, you
>> can reuse the content provider of ECP to keep the adaptations done by
>> ECP (it is used in the model explorer) or use the default one.
>>>
>>> Another question I have is related to the performance. IIRC I have read
>>> somewhere that the EMFStore loads all - local? - projects into memory.
>>> My model has two connected *-to-many references where _many_ might
>>> easily be 500 or more.
>> If you use the default persistence of EMFStore on the client side, it
>> will behave like you would store the data in an XMI file. This will
>> sooner or later effect, that all the data is in memory. It is possible
>> to improve this by using another persistence on the client, but not "for
>> free". As Ed mentioned, the performance of XMI might be enough for you.
>> I recommend to create a test model, which is let's say 10 times bigger
>> than your typical use case and test whether memory consumption is an
>> issue for you.
>>
>> Best regards
>>
>> Jonas
>>
>>>
>>> Example:
>>> A has many B and B has many C where B can be up to 1000 and C can be up
>>> to almost 400.
>>>
>>> Are there any problems I might face when loading a project of this scope
>>> into my application and what can I do to improve performance?
>>>
>>> Thanks in advance for any hints and help.
>>
>
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1250747 is a reply to message #1249424] |
Wed, 19 February 2014 14:56 |
Marina Knieling
Messages: 83
Registered: February 2013 |
Member |
|
|
Hi again,
after spending the whole day yesterday digging in the depths of ecp and
emfstore I think I finally figured out what to do to achieve what I
want. Let me share my ideas and please correct me, if I understood
something wrong.
At first, I'm working with e4, so I can't use the ecp.e3.ui stuff.
Let's say I want to use the first approach you mentioned, i.e. using the
ECP api. If I understand the concept correctly then ecp.core provides an
extension point for data providers. ecp.emfstore.core hooks into that
extension point and registers itself as data provider. So adding both
bundles to my runtime config should be enough to enable emfstore as my
data provider.
I had a look into the ecp.ui.e3 bundle in order to figure out how to
"join" the application with ecp and I especially looked at the handlers.
They only use the ECPHandlerHelper and ECPUtil classes. A further look
into the ECPHandlerHelper showed me that it depends on e3 and so I think
I have to implement my own E4ECPHandlerHelper in order to make things
work in e4. The ECPHandlerHelper also seems to be the right place to
hide the project stuff from the user by e.g. not showing him the
provider selection wizard etc.
That's for the ECP part.
I'm a bit confused when it comes to sharing the project with the local
server as there are now 3 kinds of projects: ECPProject, ESLocalProject
and ESRemoteProject. Looking at the ShareProjectHandler in the
ecp.emfstore.ui bundle, I found the InternalProject. Is this the link
between ECPProject and ESLocalProject? I don't want to use the
ShareProjectHandler because it displays UI elements that I want to hide
from the user.
My ideas was to wrap my own object with an ECPProject when I create it
using my own wizard. After creation I could share it immediately with
the local server (that will be started with the start of the
application). Is there a headless way to share the project and how do I
access it (which classes to look in)?
And a last thing: I've noticed that the ECPProject needs some
ECPProperties. Do I really need them? What do they cover and can I leave
them empty? Once again: I don't want to show the CreateProjectWizard and
so I don't know what kind of properties are stored in it.
Sorry for the long post and the many questions, but I hope to understand
the whole mechanism behind ECP and EMFStore in order to use it
appropriately in my own application and get the most out of it.
Thanks,
Marina
Am 18.02.2014 09:40, schrieb Jonas Helming:
> Hi Marina,
>
> Am 17.02.2014 13:28, schrieb Marina Knieling:
>>
>> Hi Jonas, my saviour
>>
>> thanks for your quick and detailed (as always) reply. That was the
>> answer I was hoping for.
>
> you are welcome! :-)
>
>>
>> More comments / questions below...
>>
>> Am 11.02.2014 14:48, schrieb Jonas Helming:
>>> Hi,
>>>
>>> comments below...
>>>
>>> Am 10.02.2014 22:19, schrieb Marina Knieling:
>>>> Hey guys,
>>>>
>>>> as I'm recently fed up with my database implementation and because I'm
>>>> using parts of ECP already I'm looking into EMFStore now.
>>>>
>>>> In general I only want to persist some EMF models and maybe use the
>>>> versioning feature. The application will only run on the user's local
>>>> computer and the user will be the only one who is modifying the models,
>>>> so I won't need the real repository functionality (for now, might change
>>>> later).
>>>>
>>>> Is it possible to use EMFStore without server or do I have to start a
>>>> local server (which I could hide from the user and start when the
>>>> application starts - and stop when the application is shut down)?.
>>> Absolutly! In this case, you might not even need a server at all, you
>>> could just use the client persistence of EMFStore. In the default
>>> implementation, it will just store in XMI. It therefore provides you
>>> with an abstraction of files, so you do not have to take care about
>>> files at all. The persistence is interchangable, so you can adapt this
>>> later on.
>>
>> Which bundles will I need in order to get this up and running? For the
>> ECP parts I only use the editor and I already have a customized version
>> of the ECPE4Editor and my own E4ModelElementOpener.
>>
>> I found an *ecp.emfstore bundle and then the pure emfstore.common and
>> emfstore.client and emfstore.server bundles. It seems like ecp.emfstore
>> is the data provider that is only needed if I also use the ECPProject
>> concept (which I don't, got rid of that already).
>>
>> There is an EMFStoreResource in the emfstore.common bundle and a
>> ClientXMIResourceSetProvider in the emfstore.client bundle which seems
>> to use the "simple" emf ResourceSet in contrast to the before mentioned
>> EMFStoreResource. What's the difference between them and is this even
>> the correct spot to start (i.e. do I have to do the persistence the EMF
>> way) or do I miss some API from the EMFStore?
> There are two ways of doing that. You can either use the API of ECP,
> which abstracts the functionality of the underlying data provider. This
> keeps the data provider interchangable, you could even implement your
> own data provider later on. This API is provided by the *.core bundle of
> ECP. Additionally the corresponding bundles of at least one data
> provider (e.g. EMFStore) must be running, but you do not access their
> API (they do not provide any)
>
> The second choice is to directly use the EMFStore API, have you had a
> look at this documentation:
> http://eclipse.org/emfstore/documentation.html
>
> In both cases you need to use the concept of a project, even though you
> hide it from your user. Both, ECP and EMFStore, require a project as a
> "root container". In fact the ECPProject is pointing to an EMFStore
> project, in case EMFStore is the data provider.
>
> I would generally prefer the first choice, as it keeps your backend
> interchangeable.
>
> Best Regards
>
> Jonas
>
>
>>
>>> If you want to use some local versioning, you can also start a local
>>> server. The ECP demo application allows to do that manually (right click
>>> on the local emfstore in the repository view). The bundel *localemfstore
>>> contains the corresponding code and should provide a template how you
>>> can embbed this into your applications lifecycle without manual
>>> operations by the user.
>>
>> Looked into that and looks like it's only one call to
>> EMFStoreController.runAsNewThread().
>>
>> Thanks again for your help and have a nice day
>>
>> Marina
>>
>>>>
>>>> Furthermore, my models aren't based on any project like stuff, but I
>>>> understand that I need an ESLocalProject in order to save my EMF models
>>>> to the EMFStore. Is it ok to simply create an ESLocalProject, add my
>>>> model elements and hide the project stuff from the user, performing all
>>>> the necessary tasks in the background? The reason for that is that I
>>>> don't want to confront my users with terms and processes that aren't
>>>> known to them (they rather have a musical background than a technical).
>>> Absolutly, many projects implement there own custom view to replace the
>>> model explorer at some point in time, especially, if the application
>>> does not support the concept of a "project". For this custom view, you
>>> can reuse the content provider of ECP to keep the adaptations done by
>>> ECP (it is used in the model explorer) or use the default one.
>>>>
>>>> Another question I have is related to the performance. IIRC I have read
>>>> somewhere that the EMFStore loads all - local? - projects into memory.
>>>> My model has two connected *-to-many references where _many_ might
>>>> easily be 500 or more.
>>> If you use the default persistence of EMFStore on the client side, it
>>> will behave like you would store the data in an XMI file. This will
>>> sooner or later effect, that all the data is in memory. It is possible
>>> to improve this by using another persistence on the client, but not "for
>>> free". As Ed mentioned, the performance of XMI might be enough for you.
>>> I recommend to create a test model, which is let's say 10 times bigger
>>> than your typical use case and test whether memory consumption is an
>>> issue for you.
>>>
>>> Best regards
>>>
>>> Jonas
>>>
>>>>
>>>> Example:
>>>> A has many B and B has many C where B can be up to 1000 and C can be up
>>>> to almost 400.
>>>>
>>>> Are there any problems I might face when loading a project of this scope
>>>> into my application and what can I do to improve performance?
>>>>
>>>> Thanks in advance for any hints and help.
>>>
>>
>
|
|
|
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1251544 is a reply to message #1250747] |
Thu, 20 February 2014 10:27 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi,
comments inline...
Am 19.02.2014 15:56, schrieb Marina Knieling:
> Hi again,
>
> after spending the whole day yesterday digging in the depths of ecp and
> emfstore I think I finally figured out what to do to achieve what I
> want. Let me share my ideas and please correct me, if I understood
> something wrong.
>
> At first, I'm working with e4, so I can't use the ecp.e3.ui stuff.
>
> Let's say I want to use the first approach you mentioned, i.e. using the
> ECP api. If I understand the concept correctly then ecp.core provides an
> extension point for data providers. ecp.emfstore.core hooks into that
> extension point and registers itself as data provider. So adding both
> bundles to my runtime config should be enough to enable emfstore as my
> data provider.
correct.
>
> I had a look into the ecp.ui.e3 bundle in order to figure out how to
> "join" the application with ecp and I especially looked at the handlers.
> They only use the ECPHandlerHelper and ECPUtil classes. A further look
> into the ECPHandlerHelper showed me that it depends on e3 and so I think
> I have to implement my own E4ECPHandlerHelper in order to make things
> work in e4. The ECPHandlerHelper also seems to be the right place to
> hide the project stuff from the user by e.g. not showing him the
> provider selection wizard etc.
For 1.2, we removed the dependency to 3.x. We ahev a bundle for e3 and
one for e4 providing the handlers. The both access the core, which
actually implements the functionality. Please note that the e4 support
is very new, so if you experience any issue, please report.
>
> That's for the ECP part.
>
> I'm a bit confused when it comes to sharing the project with the local
> server as there are now 3 kinds of projects: ECPProject, ESLocalProject
> and ESRemoteProject. Looking at the ShareProjectHandler in the
> ecp.emfstore.ui bundle, I found the InternalProject. Is this the link
> between ECPProject and ESLocalProject? I don't want to use the
> ShareProjectHandler because it displays UI elements that I want to hide
> from the user.
>
ECPProject is the ECP abstraction of a project and is independant of the
data provider. InternalProject is just the internal interface to be used
by the data provider (SPI). The link between an ECPProject and the
EMFStore project is done by the EMFStoreProvider.
ESLocalProject and ESRemote Project are both EMFStore interfaces.
> My ideas was to wrap my own object with an ECPProject when I create it
> using my own wizard. After creation I could share it immediately with
> the local server (that will be started with the start of the
> application). Is there a headless way to share the project and how do I
> access it (which classes to look in)?
In this case, the ECP API is not suitable for you. Features such as
"share" are offered by the API, but not in a headless way. You therefore
will need to directly use the EMFStore API, which allows to trigger all
functions you need also without any UI. Have you had a look at the
EMFStore tutorials?
>
> And a last thing: I've noticed that the ECPProject needs some
> ECPProperties. Do I really need them? What do they cover and can I leave
> them empty? Once again: I don't want to show the CreateProjectWizard and
> so I don't know what kind of properties are stored in it.
You do not need any properties, I think...
>
> Sorry for the long post and the many questions, but I hope to understand
> the whole mechanism behind ECP and EMFStore in order to use it
> appropriately in my own application and get the most out of it.
>
> Thanks,
>
> Marina
>
>
> Am 18.02.2014 09:40, schrieb Jonas Helming:
>> Hi Marina,
>>
>> Am 17.02.2014 13:28, schrieb Marina Knieling:
>>>
>>> Hi Jonas, my saviour
>>>
>>> thanks for your quick and detailed (as always) reply. That was the
>>> answer I was hoping for.
>>
>> you are welcome! :-)
>>
>>>
>>> More comments / questions below...
>>>
>>> Am 11.02.2014 14:48, schrieb Jonas Helming:
>>>> Hi,
>>>>
>>>> comments below...
>>>>
>>>> Am 10.02.2014 22:19, schrieb Marina Knieling:
>>>>> Hey guys,
>>>>>
>>>>> as I'm recently fed up with my database implementation and because I'm
>>>>> using parts of ECP already I'm looking into EMFStore now.
>>>>>
>>>>> In general I only want to persist some EMF models and maybe use the
>>>>> versioning feature. The application will only run on the user's local
>>>>> computer and the user will be the only one who is modifying the
>>>>> models,
>>>>> so I won't need the real repository functionality (for now, might
>>>>> change
>>>>> later).
>>>>>
>>>>> Is it possible to use EMFStore without server or do I have to start a
>>>>> local server (which I could hide from the user and start when the
>>>>> application starts - and stop when the application is shut down)?.
>>>> Absolutly! In this case, you might not even need a server at all, you
>>>> could just use the client persistence of EMFStore. In the default
>>>> implementation, it will just store in XMI. It therefore provides you
>>>> with an abstraction of files, so you do not have to take care about
>>>> files at all. The persistence is interchangable, so you can adapt this
>>>> later on.
>>>
>>> Which bundles will I need in order to get this up and running? For the
>>> ECP parts I only use the editor and I already have a customized version
>>> of the ECPE4Editor and my own E4ModelElementOpener.
>>>
>>> I found an *ecp.emfstore bundle and then the pure emfstore.common and
>>> emfstore.client and emfstore.server bundles. It seems like ecp.emfstore
>>> is the data provider that is only needed if I also use the ECPProject
>>> concept (which I don't, got rid of that already).
>>>
>>> There is an EMFStoreResource in the emfstore.common bundle and a
>>> ClientXMIResourceSetProvider in the emfstore.client bundle which seems
>>> to use the "simple" emf ResourceSet in contrast to the before mentioned
>>> EMFStoreResource. What's the difference between them and is this even
>>> the correct spot to start (i.e. do I have to do the persistence the EMF
>>> way) or do I miss some API from the EMFStore?
>> There are two ways of doing that. You can either use the API of ECP,
>> which abstracts the functionality of the underlying data provider. This
>> keeps the data provider interchangable, you could even implement your
>> own data provider later on. This API is provided by the *.core bundle of
>> ECP. Additionally the corresponding bundles of at least one data
>> provider (e.g. EMFStore) must be running, but you do not access their
>> API (they do not provide any)
>>
>> The second choice is to directly use the EMFStore API, have you had a
>> look at this documentation:
>> http://eclipse.org/emfstore/documentation.html
>>
>> In both cases you need to use the concept of a project, even though you
>> hide it from your user. Both, ECP and EMFStore, require a project as a
>> "root container". In fact the ECPProject is pointing to an EMFStore
>> project, in case EMFStore is the data provider.
>>
>> I would generally prefer the first choice, as it keeps your backend
>> interchangeable.
>>
>> Best Regards
>>
>> Jonas
>>
>>
>>>
>>>> If you want to use some local versioning, you can also start a local
>>>> server. The ECP demo application allows to do that manually (right
>>>> click
>>>> on the local emfstore in the repository view). The bundel
>>>> *localemfstore
>>>> contains the corresponding code and should provide a template how you
>>>> can embbed this into your applications lifecycle without manual
>>>> operations by the user.
>>>
>>> Looked into that and looks like it's only one call to
>>> EMFStoreController.runAsNewThread().
>>>
>>> Thanks again for your help and have a nice day
>>>
>>> Marina
>>>
>>>>>
>>>>> Furthermore, my models aren't based on any project like stuff, but I
>>>>> understand that I need an ESLocalProject in order to save my EMF
>>>>> models
>>>>> to the EMFStore. Is it ok to simply create an ESLocalProject, add my
>>>>> model elements and hide the project stuff from the user, performing
>>>>> all
>>>>> the necessary tasks in the background? The reason for that is that I
>>>>> don't want to confront my users with terms and processes that aren't
>>>>> known to them (they rather have a musical background than a
>>>>> technical).
>>>> Absolutly, many projects implement there own custom view to replace the
>>>> model explorer at some point in time, especially, if the application
>>>> does not support the concept of a "project". For this custom view, you
>>>> can reuse the content provider of ECP to keep the adaptations done by
>>>> ECP (it is used in the model explorer) or use the default one.
>>>>>
>>>>> Another question I have is related to the performance. IIRC I have
>>>>> read
>>>>> somewhere that the EMFStore loads all - local? - projects into memory.
>>>>> My model has two connected *-to-many references where _many_ might
>>>>> easily be 500 or more.
>>>> If you use the default persistence of EMFStore on the client side, it
>>>> will behave like you would store the data in an XMI file. This will
>>>> sooner or later effect, that all the data is in memory. It is possible
>>>> to improve this by using another persistence on the client, but not
>>>> "for
>>>> free". As Ed mentioned, the performance of XMI might be enough for you.
>>>> I recommend to create a test model, which is let's say 10 times bigger
>>>> than your typical use case and test whether memory consumption is an
>>>> issue for you.
>>>>
>>>> Best regards
>>>>
>>>> Jonas
>>>>
>>>>>
>>>>> Example:
>>>>> A has many B and B has many C where B can be up to 1000 and C can
>>>>> be up
>>>>> to almost 400.
>>>>>
>>>>> Are there any problems I might face when loading a project of this
>>>>> scope
>>>>> into my application and what can I do to improve performance?
>>>>>
>>>>> Thanks in advance for any hints and help.
>>>>
>>>
>>
>
|
|
| |
| Re: [EMFStore][EMFClient] Using the EMFStore for simple storage [message #1256926 is a reply to message #1256490] |
Tue, 25 February 2014 23:41 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Am 25.02.2014 14:37, schrieb Marina Knieling:
> Hi again,
>
> comments below...
>
>>> My ideas was to wrap my own object with an ECPProject when I create it
>>> using my own wizard. After creation I could share it immediately with
>>> the local server (that will be started with the start of the
>>> application). Is there a headless way to share the project and how do I
>>> access it (which classes to look in)?
>> In this case, the ECP API is not suitable for you. Features such as
>> "share" are offered by the API, but not in a headless way. You therefore
>> will need to directly use the EMFStore API, which allows to trigger all
>> functions you need also without any UI. Have you had a look at the
>> EMFStore tutorials?
>>
>
> I'm still a bit confused about this part of your explanation.
> I had a look at the EMFStore tutorials and I managed to start my own
> server at application startup and to obtain the workspace.
> When I create my object O in my own wizard, I create an ESLocalProject,
> add the object O to it and share it to my server. This works, as I can
> see the files in the .emfstore folder on my disk.
>
> The problem I now have is, how do I use the ECP editor now? I've found
> the implementation of the E4ModelElementOpener and the E4 version of the
> ECPModelView which uses the ECPHandlerHelper which in turn needs the
> ECPProject.
> If I understand everything correctly I can use my own ModelView (e.g. a
> simple ListViewer) and register the E4ModelElementOpener via the
> extension point. In my ListViewer I can add a DoubleClickListener and
> call the ECPHandlerHelper method openModelElement. But this needs an
> ECPProject. Where do I get this from? Or can I - in this case - get rid
> of the ECPProject? I already did this once before.
You can absolutly use the editor without an ECPProject. Please refer to:
http://eclipsesource.com/blogs/tutorials/emf-client-platform-how-to-customize-the-editor-layout/#tutorial
at the bottom (embed the editor)
If you use reference controls, you need to implement and add a reference
service, too.
Best regards
Jonas
>
> Thanks for any hints
> Marina
>
>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 16:28:58 GMT 2024
Powered by FUDForum. Page generated in 0.03637 seconds |
] 
Search
Help
Register
Login
Home
