Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF + CouchDB
EMF + CouchDB [message #479556] Tue, 11 August 2009 14:26 Go to next message
Roland Tepp is currently offline Roland TeppFriend
Messages: 336
Registered: July 2009
Senior Member
Has anybody implemented ResourceSet for persisting EMF models to CouchDB
yet?
Re: EMF + CouchDB [message #479557 is a reply to message #479556] Tue, 11 August 2009 14:35 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Roland,

I'm pretty sure that not. How can I know? Because one would extend
ResourceImpl to provide custom persistence in EMF ;-)

I don't know of any Resource implementation with support for CouchDB. Is
that an SQL DB?

There are two components of EMF that offer custom persistence:

1) Teneo --> http://www.eclipse.org/modeling/emf/?project=teneo
2) CDO Model Repository --> http://wiki.eclipse.org/CDO

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Roland Tepp schrieb:
> Has anybody implemented ResourceSet for persisting EMF models to
> CouchDB yet?
Re: EMF + CouchDB [message #479558 is a reply to message #479557] Tue, 11 August 2009 14:48 Go to previous messageGo to next message
Roland Tepp is currently offline Roland TeppFriend
Messages: 336
Registered: July 2009
Senior Member
Hi Eike,

CouchDB is _not_ an SQL db, that is why I asked :)

Basically - CouchDB[1] is a database for storing arbitrary JSON documents.

It seems to me the the persistence model of CouchDB is pretty nice fit
for EMF persistence...

[1] http://couchdb.apache.org/

11.08.2009 17:35, Eike Stepper kirjutas:
> I'm pretty sure that not. How can I know? Because one would extend
> ResourceImpl to provide custom persistence in EMF;-)
>
> I don't know of any Resource implementation with support for CouchDB. Is
> that an SQL DB?
Re: EMF + CouchDB [message #479566 is a reply to message #479558] Tue, 11 August 2009 15:00 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26283
Registered: July 2009
Senior Member
Roland,

A fundamental "problem" with JSON as a general serialization format for
EMF instances is lack of support for something equivalent to xsi:type.
When we deserialize we always need to know what type of object to create
to hold the subsequent data. Certainly we can always try to create an
instance of the feature's type, but often the actual serialized instance
is a subtype of the feature's type and we need to know that up front.
This makes JSON a poor fit for representing strongly/explicitly typed
instances without some additional conventions...


Roland Tepp wrote:
> Hi Eike,
>
> CouchDB is _not_ an SQL db, that is why I asked :)
>
> Basically - CouchDB[1] is a database for storing arbitrary JSON
> documents.
>
> It seems to me the the persistence model of CouchDB is pretty nice fit
> for EMF persistence...
>
> [1] http://couchdb.apache.org/
>
> 11.08.2009 17:35, Eike Stepper kirjutas:
>> I'm pretty sure that not. How can I know? Because one would extend
>> ResourceImpl to provide custom persistence in EMF;-)
>>
>> I don't know of any Resource implementation with support for CouchDB. Is
>> that an SQL DB?
>
Re: EMF + CouchDB [message #479570 is a reply to message #479566] Tue, 11 August 2009 15:17 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 5487
Registered: July 2009
Senior Member
Hi,

There are JSON-Serialization formats (in end this are common rules) who
store the value of the type in a "special" feature like (@type :
"com.bla.Bla").

E.g. jersey serializes/deserializes JSON-Data with the help of this IIRC
giving you the possibility to use your objects in REST very easy :-)

Tom

Ed Merks schrieb:
> Roland,
>
> A fundamental "problem" with JSON as a general serialization format for
> EMF instances is lack of support for something equivalent to xsi:type.
> When we deserialize we always need to know what type of object to create
> to hold the subsequent data. Certainly we can always try to create an
> instance of the feature's type, but often the actual serialized instance
> is a subtype of the feature's type and we need to know that up front.
> This makes JSON a poor fit for representing strongly/explicitly typed
> instances without some additional conventions...
>
>
> Roland Tepp wrote:
>> Hi Eike,
>>
>> CouchDB is _not_ an SQL db, that is why I asked :)
>>
>> Basically - CouchDB[1] is a database for storing arbitrary JSON
>> documents.
>>
>> It seems to me the the persistence model of CouchDB is pretty nice fit
>> for EMF persistence...
>>
>> [1] http://couchdb.apache.org/
>>
>> 11.08.2009 17:35, Eike Stepper kirjutas:
>>> I'm pretty sure that not. How can I know? Because one would extend
>>> ResourceImpl to provide custom persistence in EMF;-)
>>>
>>> I don't know of any Resource implementation with support for CouchDB. Is
>>> that an SQL DB?
>>
Re: EMF + CouchDB [message #479579 is a reply to message #479570] Tue, 11 August 2009 15:45 Go to previous messageGo to next message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 130
Registered: July 2009
Senior Member
Hi

I am working in a similar setup. I have an EMF Model im my Eclipse
client (RCP) and I communicate on behalf of ECF-REST with a
REST-Service, that wants json. I therefore experienced these limitations
and tried to get rid of them. I'd like to share what I found out so far:

A possibility to overcome the limited types-set would be a json-scheme,
as proposed here:
http://json-schema.org/

I'm not quite sure, but I thought jackson already supports this.

The other limitation, that is the lack of references is covered by
another proposal, json referencing:
http://www.json.com/2007/10/19/json-referencing-proposal-and -library/
http://www.jspon.org/
http://www.sitepen.com/blog/2008/06/17/json-referencing-in-d ojo/

I don't know of any java library that supports this, but might be a good
starting point to research possibilities.

Cheers
André


Tom Schindl wrote:
> Hi,
>
> There are JSON-Serialization formats (in end this are common rules) who
> store the value of the type in a "special" feature like (@type :
> "com.bla.Bla").
>
> E.g. jersey serializes/deserializes JSON-Data with the help of this IIRC
> giving you the possibility to use your objects in REST very easy :-)
>
> Tom
>
> Ed Merks schrieb:
>> Roland,
>>
>> A fundamental "problem" with JSON as a general serialization format for
>> EMF instances is lack of support for something equivalent to xsi:type.
>> When we deserialize we always need to know what type of object to create
>> to hold the subsequent data. Certainly we can always try to create an
>> instance of the feature's type, but often the actual serialized instance
>> is a subtype of the feature's type and we need to know that up front.
>> This makes JSON a poor fit for representing strongly/explicitly typed
>> instances without some additional conventions...
>>
>>
>> Roland Tepp wrote:
>>> Hi Eike,
>>>
>>> CouchDB is _not_ an SQL db, that is why I asked :)
>>>
>>> Basically - CouchDB[1] is a database for storing arbitrary JSON
>>> documents.
>>>
>>> It seems to me the the persistence model of CouchDB is pretty nice fit
>>> for EMF persistence...
>>>
>>> [1] http://couchdb.apache.org/
>>>
>>> 11.08.2009 17:35, Eike Stepper kirjutas:
>>>> I'm pretty sure that not. How can I know? Because one would extend
>>>> ResourceImpl to provide custom persistence in EMF;-)
>>>>
>>>> I don't know of any Resource implementation with support for CouchDB. Is
>>>> that an SQL DB?
Re: EMF + CouchDB [message #479656 is a reply to message #479579] Tue, 11 August 2009 21:00 Go to previous message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 130
Registered: July 2009
Senior Member
Just a few word to another possible solution:

Use Xtext to declare the grammar of your object model. Doing so, you
declare the mapping that rules your Ecore/Json. Xtext has a custom
resource implementation that stores the instances in your own json based
DSL. Of course, the Xtext resource stores to files like the default
resource does. Extend this one to use CouchDb instead of files shoudn't
be too hard, I guess.
I just needed the serialization/de-, not a plain persistence solution. I
did a PoC using Xtext and I was pretty amazed by its slickness.

Cheers
André

Ande Dietisheim wrote:
> Hi
>
> I am working in a similar setup. I have an EMF Model im my Eclipse
> client (RCP) and I communicate on behalf of ECF-REST with a
> REST-Service, that wants json. I therefore experienced these limitations
> and tried to get rid of them. I'd like to share what I found out so far:
>
> A possibility to overcome the limited types-set would be a json-scheme,
> as proposed here:
> http://json-schema.org/
>
> I'm not quite sure, but I thought jackson already supports this.
>
> The other limitation, that is the lack of references is covered by
> another proposal, json referencing:
> http://www.json.com/2007/10/19/json-referencing-proposal-and -library/
> http://www.jspon.org/
> http://www.sitepen.com/blog/2008/06/17/json-referencing-in-d ojo/
>
> I don't know of any java library that supports this, but might be a good
> starting point to research possibilities.
>
> Cheers
> André
>
>
> Tom Schindl wrote:
>> Hi,
>>
>> There are JSON-Serialization formats (in end this are common rules) who
>> store the value of the type in a "special" feature like (@type :
>> "com.bla.Bla").
>>
>> E.g. jersey serializes/deserializes JSON-Data with the help of this IIRC
>> giving you the possibility to use your objects in REST very easy :-)
>>
>> Tom
>>
>> Ed Merks schrieb:
>>> Roland,
>>>
>>> A fundamental "problem" with JSON as a general serialization format for
>>> EMF instances is lack of support for something equivalent to
>>> xsi:type. When we deserialize we always need to know what type of
>>> object to create
>>> to hold the subsequent data. Certainly we can always try to create an
>>> instance of the feature's type, but often the actual serialized instance
>>> is a subtype of the feature's type and we need to know that up front.
>>> This makes JSON a poor fit for representing strongly/explicitly typed
>>> instances without some additional conventions...
>>>
>>>
>>> Roland Tepp wrote:
>>>> Hi Eike,
>>>>
>>>> CouchDB is _not_ an SQL db, that is why I asked :)
>>>>
>>>> Basically - CouchDB[1] is a database for storing arbitrary JSON
>>>> documents.
>>>>
>>>> It seems to me the the persistence model of CouchDB is pretty nice fit
>>>> for EMF persistence...
>>>>
>>>> [1] http://couchdb.apache.org/
>>>>
>>>> 11.08.2009 17:35, Eike Stepper kirjutas:
>>>>> I'm pretty sure that not. How can I know? Because one would extend
>>>>> ResourceImpl to provide custom persistence in EMF;-)
>>>>>
>>>>> I don't know of any Resource implementation with support for
>>>>> CouchDB. Is
>>>>> that an SQL DB?
>
Previous Topic:grouping containments for tree ui - unnecessary?
Next Topic:replace gen Date instead of XMLGregorianCalendar
Goto Forum:
  


Current Time: Sat Dec 20 06:38:04 GMT 2014

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

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