|
|
|
|
|
| Re: EMF + CouchDB [message #479579 is a reply to message #479570] |
Tue, 11 August 2009 15:45   |
 Andre Dietisheim
Messages: 131
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 |
Andre Dietisheim
Messages: 131
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?
>
|
|
|
Powered by
FUDForum. Page generated in 0.15580 seconds
] 
Search
Help
Register
Login
Home
