Hi,
Re 1: The Version attribute is crucial, I've added a top-level property as a
counterpart of the Version attribute, modified examples and XSL transformation
have been checked into SVN:
https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/examples/#_trunk_spec_examples_.
{
"$schema":"http://docs.oasis-open.org/odata/odata-json-csdl/v4.0/edm.json#";,
"odata-version":"4.0",
"schemas":...
}
The edmx:DataServices element on the other hand is just a wrapper/container for
the edm:Schema elements without any semantics attached to it, which is why we
don't represent it in the JSON $metadata.
I suggest removing the getDataServices() method and the DataServices interface
from the Olingo API and moving the getSchemas method up to the Edmx interface.
The remaining two methods of the DataServices interface, getDataServiceVersion
and getMaxDataServiceVersion, are obsolete anyway, the edmx:DataServices
element does not have any attributes.
Thanks in advance!
--Ralf
-----Original Message-----
From: Amend, Christian [mailto:[email protected]]
Sent: Mittwoch, 15. Juli 2015 08:44
To: [email protected]
Cc: Kevin Ratnasekera
Subject: RE: JSON Metadata Document client side deserializer
Hi Kevin,
1. Ok then we will leave the interface in the API. But I will address
this at the OData committee since there should be no information difference
between the two documents.
2. Yes please think about it and let me know if you have another idea. In
the meantime I think that your arguments about modularity weigh more than
having just one internal class because it looks nice from the outside. So
please go ahead with the approach you have started with.
3. Thanks ☺
If you have any questions about design decisions we took with Olingo let me
know and we will sort it out.
Best regards,
Christian
From: Kevin Ratnasekera [mailto:[email protected]]
Sent: Montag, 13. Juli 2015 21:45
To: Amend, Christian; Christian Amend
Cc: [email protected]
Subject: Re: JSON Metadata Document client side deserializer
Hi Christian,
Please find my answers to your questions,
1. Why is the interface “EdmJsonSchema” visible in the API? For a client
it should not matter if he deserializes a Json or XML Metadata Document.
Yes this is true, but if you compare two metadata documents JSON and XML, json
metadata document does not have dataservices tag and version compared to its
xml document. I thought it was inappropriate to extend the Edmx interface for
the with has getDataservises () getVersion() abstract methods since, those are
no longer valid here. EdmJsonSchema and Edmx interfaces refers two counter
parts of metadata document two types, and the implementations of these two
interfaces are ClientJsonSchemaCsdl and ClientCsdlEdmx. If you look at the
classes this is part of a deserialization of two metadata documents, I have too
implemented the API XMLMetadata interface for the JsonMetadata document by
ClientCsdlJSONMetadata, final out come of metadata is just same for the two
cases.
2. You have used the existing Architecture where every type of Edm object
results in a separate class which always calls the parser.getCodec().readTree()
method. If you are using the JacksonParser library and parse the tree manually
instead of using annotations why not follow the approach of writing a single
parser class which reads the whole Json Metadata document in one go. Please
have a look at the JsonDerserializer.entity() method in the server core
package. This is what I would have thought about when you said you would like
to write a custom deserializer. If you follow the approach on the server more
closely you don´t have to replicate so many classes. Maybe this would make it
easier on client side as well.
Sorry If I made you misunderstand, I think I have mentioned about writing
custom deserializer per metadata document element, so there will several
deserializer classes in this mail thread. Actually I wanted to follow the token
based approach (not parsing entire tree once and build the model) similar to
what current client-core currently has for the XML metadata document, This
architecture follows writing multiple deserializer classes activated when parse
through the tree, But as I did mentioned to you because of the dependency
having between the definitions and schemas with the newly introduced
definitions filed json metadata document, this field get deserialized first
before the schema field. That is why I had to look for other approach which you
mentioned. Yes, I agree with you completely writing a single class will do the
thing. This approach basically each deserializer handles part of the document.
I have looked several the deserializer implementations of Olingo library.This
the same for the Json Service Document deserializer for client-core follows.
But I wanted to follow the architecture what exist for the xml document has so
my implementation will look similar to that. Other than that I see several
advantages of this approach such as increase modularity of code, that will lead
to better cohesive, understandable, reusable code.
Anyway with the issues I faced, I will have to rethink about the way things get
deserialized inside jackson library, because as I see, there can be several way
of doing the same thing. May be there are other workarounds too for the issues
I faces. I will look more into this too as I am not very familiar with the
jackson.
3. The logic to split a type name is already implemented in the
FullQualifiedName class. Could you ruse that logic in your code or do yoou have
to react to specific parts of the type name?
Yes, completely agree with you, I will do the changes.
I am really thankful for you taking time to review my code :)
Regards
Kevin
On Mon, Jul 13, 2015 at 11:14 PM, Kevin Ratnasekera
<[email protected]<mailto:[email protected]>> wrote:
Hi Christian,
Please find my answers to yours questions,
1. Why is the interface “EdmJsonSchema” visible in the API? For a client
it should not matter if he deserializes a Json or XML Metadata Document.
Yes this is true, but if you compare two metadata documents JSON and XML, json
metadata document does not have dataservices tag and version compared to its
xml document. I though it was inappropriate to extend the
Edmx interface for the with has getDataservises () getVersion() abstract
methods since, those are no longer valid here.
On Mon, Jul 13, 2015 at 9:20 PM, Amend, Christian
<[email protected]<mailto:[email protected]>> wrote:
Hi Kevin,
I had a look at your code and it seems good although I have some questions:
1. Why is the interface “EdmJsonSchema” visible in the API? For a client
it should not matter if he deserializes a Json or XML Metadata Document.
2. You have used the existing Architecture where every type of Edm object
results in a separate class which always calls the parser.getCodec().readTree()
method. If you are using the JacksonParser library and parse the tree manually
instead of using annotations why not follow the approach of writing a single
parser class which reads the whole Json Metadata document in one go. Please
have a look at the JsonDerserializer.entity() method in the server core
package. This is what I would have thought about when you said you would like
to write a custom deserializer. If you follow the approach on the server more
closely you don´t have to replicate so many classes. Maybe this would make it
easier on client side as well.
3. The logic to split a type name is already implemented in the
FullQualifiedName class. Could you ruse that logic in your code or do yoou have
to react to specific parts of the type name?
Let me know what you think about these points ☺
Aside from that the code you wrote to put the json definition parts into their
respective bean classes looks good to me. Using the CSDL… classes is the right
approach to store the data. This way the EDM implementation can be reused.
Best Regards,
Christian
From: Kevin Ratnasekera
[mailto:[email protected]<mailto:[email protected]>]
Sent: Sonntag, 12. Juli 2015 20:15
To: Amend, Christian; Christian Amend
Cc: [email protected]<mailto:[email protected]>
Subject: Re: JSON Metadata Document client side deserializer
Hi Christian/Olingo Community,
As I have mentioned in my previous email, I have come with a for first
prototype for the client side Json metadata document deserialization using
custom json deserializers. With my latest commit[1] i have pushed the changes
for prototype. First prototype has the following deserializers , definitions -
enum type (done-done) , references - includes and include annotations
(done-done), definitions - entity type ( partially done ) , and
schemas - entity set ( partially done ). This changes commit is somewhat lager
but I have added in the purpose of getting the big picture. They may look
similar when compared to the current deserializer implementation in client-core
but there are some changes you will notice. I will more document these with
google doc for the project, cases where I had some issues how I overcame those
issues using Jackson library. I have added test cases for support the prototype
too. Please have look at it and provide me some feedback so that I can proceed
with implementation of the rest.
Regards
Kevin
[1]https://github.com/djkevincr/olingo-odata4/commit/ebecb573fc7917533afe8d3f90fa2e6522f671fd
On Fri, Jul 10, 2015 at 2:30 PM, Amend, Christian
<[email protected]<mailto:[email protected]>> wrote:
Hi Kevin,
Thanks. I applied the changes to the Apache jsonMetadata branch and all tests
are now working for me. I also packed you commits in diff files and attached
them to the JIRA issue as a future reference. Keep up the good work ☺
Best Regards,
Christian
From: Kevin Ratnasekera
[mailto:[email protected]<mailto:[email protected]>]
Sent: Donnerstag, 9. Juli 2015 21:20
To: [email protected]<mailto:[email protected]>; Amend, Christian
Subject: Re: JSON Metadata Document client side deserializer
Hi Christian,
With my latest commit, I have added a fix for test case failures due to setting
default pretty printer to Jackson json generator. If you still have issues
running test cases for metadata document json serializer, Please let me know.
I will come with prototype very soon too.
[1]https://github.com/djkevincr/olingo-odata4/commit/e20f35268638d44785c967e17ec647a65460102b
Regards
Kevin
On Tue, Jul 7, 2015 at 1:28 AM, Kevin Ratnasekera
<[email protected]<mailto:[email protected]>> wrote:
Hi Christian,
I agree with your concerns, I will come with a prototype as soon as possible to
get your feedback proceed forward.
Regards
Kevin
On Mon, Jul 6, 2015 at 2:02 PM, Amend, Christian
<[email protected]<mailto:[email protected]>> wrote:
Hi Kevin,
your idea of using a custom deserializer instead of pure annotations sounds
very good to me. This would make it easier to first deserialize the existing
schemas and then move to the type definitions afterwards. This way you already
have the schema CSDL classes ready and can attach the types as you deserialize
them. I am looking forward to a first prototype ☺
About the general architecture: I would suggest that the deserializer should
not validate the document it is parsing for semantics. This means that if a
server sends a metadata document that contains an entity set with a type that
is not present we do not throw an exception during parsing. This is to save
performance for bigger metadata documents and also because a server should
always send a valid metadata document.
WDYT?
Best Regards,
Christian
From: Kevin Ratnasekera
[mailto:[email protected]<mailto:[email protected]>]
Sent: Samstag, 4. Juli 2015 21:49
To: [email protected]<mailto:[email protected]>
Cc: Amend, Christian;
[email protected]<mailto:[email protected]>
Subject: JSON Metadata Document client side deserializer
Hi Olingo Community,
Regarding the Json metadata document GSoC project currently I have progressed
upto the metadata document serialization at the server side. [1] Now I have
moved implementation of client side metadata document de-serialization.
When I have look at the current Service Document Json deserializer and metadata
document xml deserialzer in client core lib, the approach which is used to
deserialize either Json and xml payloads of metadata/service document is
writing custom Jackson deserializer classes. For the Json service document a
single custom deserializer ( JSONServiceDocumentDeserializer ) is being used,
and for the xml metadata document case set of deserializer classes for parts of
metadata document (EntityContainerDeserialize, ReferenceDeserializer) and they
are registered on jackson mapper object using annotations first and then called
recursively when we go through the each element of metadata document when
parsing the relevant payload.
I am thinking of adapting the similar approach to Json metadata document
deserialization, basically to write Jackson custom deserializer classes for
json metadata document elements similar to xml case ( but there are some
changes documents). I see some advantages of this basically this approach is
complaint with the current approach, custom deserializer classes are more
robust and adaptable complex custom cases when compared to approaches just
simply use Jackson annotations to map json fields to java object fields.
Are there any other approaches available to achieve this? And What should be
the best approach to use?
Regards
Kevin
[1]https://github.com/djkevincr/olingo-odata4/tree/jsonMetadata
