|
| Re: EMFStore [message #1080641 is a reply to message #1080566] |
Tue, 06 August 2013 07:47   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Murthy,
You should also have a look at Teneo and at CDO, both of which provide
support for persisting model instances in a DB. As far as I understand
it, EMFStore is more like CVS/SVN/Git in that it allows you to store
whatever file-based serialization you already have into a file-based
repository...
On 06/08/2013 7:20 AM, Murthy Bhat wrote:
> Hello,
> We have an eclipse based application where the data has been modeled
> using EMF. I have tons of EMF models in my business logic and I want
> to save it some where so that I can load/search in future. The data is
> not very relational, but only contains references, containment,
> aggregations etc.Instead of saving them as plain XMI/XML, we want a
> better data storage mechanism (something like a DB?). Any
> thoughts/suggestions ?
>
> I came across EMFStore and found it quite interesting for EMF Model
> serializing needs. Could someone help me to understand if EMFStore
> could be used as a data store alone and fits my specific use case ?
>
> Thanks in advance for help.
>
> -Murthy
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMFStore [message #1080728 is a reply to message #1080641] |
Tue, 06 August 2013 10:13 |
Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Murthy,
@Ed: what you understood about EMFStore is wrong! ;-))
EMFStore is a model repository with the abstraction level being models
not files. It is intended to support multiple users changing one model
collaboratively including conflict detection and interactive merging.
The control flow for multiuser is indeed similar to CVS/SVN/GIT with
checkout, commit, update, etc. but everything based on models not on
files. For example a commit is sending a list of model changes to the
server.
It is certainly worthwhile to look at Teneo and CDO also, it all depends
on your requirements. Do not hesitate to contact me about your
requirements to find out if EMFStore is a match.
Cheers,
Maximilian
Am 06.08.2013 09:47, schrieb Ed Merks:
> Murthy,
>
> You should also have a look at Teneo and at CDO, both of which provide
> support for persisting model instances in a DB. As far as I understand
> it, EMFStore is more like CVS/SVN/Git in that it allows you to store
> whatever file-based serialization you already have into a file-based
> repository...
>
>
> On 06/08/2013 7:20 AM, Murthy Bhat wrote:
>> Hello,
>> We have an eclipse based application where the data has been modeled
>> using EMF. I have tons of EMF models in my business logic and I want
>> to save it some where so that I can load/search in future. The data is
>> not very relational, but only contains references, containment,
>> aggregations etc.Instead of saving them as plain XMI/XML, we want a
>> better data storage mechanism (something like a DB?). Any
>> thoughts/suggestions ?
>>
>> I came across EMFStore and found it quite interesting for EMF Model
>> serializing needs. Could someone help me to understand if EMFStore
>> could be used as a data store alone and fits my specific use case ?
>>
>> Thanks in advance for help.
>>
>> -Murthy
>
--
Maximilian Kögel
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
|
| Re: EMFStore [message #1081315 is a reply to message #1081306] |
Wed, 07 August 2013 04:35 |
|
Hi Murthy,
Comments below...
Am 07.08.2013 06:20, schrieb Murthy Bhat:
> Thank you Ed, Thank you Maximilian.
>
> I am looking at Teneo and CDO
I will give you some hints for CDO in the light of your requirements below.
> right now and I would'nt mind giving EMFStore a shot as well. Below are my requirements.
>
> We have a OSGi based web application
CDO can be used with or without OSGi. With it the setup and configuration is a little easier.
> (eclipse bundles running in Virgo)
I haven't tested CDO with Virgo.
> where we have EMF models on the server side.
With CDO your models can grow arbitrarily large on the server side because CDO clients support demand loading and
automatic memory management on the object granule.
> It is a collaborative environment where a model could be shared between two or more different sessions.
CDO supports real-time collaboration.
> Apart from the versioning/collaborative requirements,
CDO supports transparent temporality and branching.
> the basic requirement is to have a model(data) repository where we could run operations like Create, Read, Update,
> Delete,
CDO users seem to favour pessimistic object locking over conflict resolution. Both are possible, though.
> Search
CDO comes with a query framework that frees you from loading all objects onto the clients when searching for particular
objects. SQL and OCL are two of the supported query languages.
> etc. Any thoughts/suggestions ?
> Thanks in advance for help.
http://www.eclipse.org/cdo/documentation gives a functional and architectural overview of CDO. Please don't hesitate to
ask more questions (but please use the EMF newsgroup / forum).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.03283 seconds
] 
Search
Help
Register
Login
Home
