Hi Christian, I will focus on the deserializer and finish it, this doesn't give me any trouble. I will give you a update regarding completing rest of the deserializer soon. Regards Kevin
On Fri, Jul 17, 2015 at 1:00 PM, Amend, Christian <christian.am...@sap.com> wrote: > Hi Kevin, > > > > if deleting the DataServices Interface is too much trouble you can leave > that away and focus on finishing the deserializer. This we can also > refactor on the master branch. Let me know what you think. > > > > Best Regards, > > Christian > > > > *From:* Kevin Ratnasekera [mailto:djkevincr1...@gmail.com] > *Sent:* Freitag, 17. Juli 2015 08:52 > *To:* Amend, Christian > > *Cc:* dev@olingo.apache.org > *Subject:* Re: JSON Metadata Document client side deserializer > > > > Hi Christian, > > I have added the odata-version to the metadata document json serializer > with the latest commit. I will work on the rest. > > Regards > > Kevin > > > > On Thu, Jul 16, 2015 at 6:13 PM, Amend, Christian <christian.am...@sap.com> > wrote: > > Hi Kevin, > > > > thanks for picking this up J . Please also adjust the server serializer > code to include the version attribute. > > > > Best Regards, > > Christian > > > > *From:* Kevin Ratnasekera [mailto:djkevincr1...@gmail.com] > *Sent:* Donnerstag, 16. Juli 2015 14:12 > *To:* Handl, Ralf; Amend, Christian > *Cc:* dev@olingo.apache.org > *Subject:* Re: JSON Metadata Document client side deserializer > > > > Hi all, > > I am really thankful for your reviews/explanations, I will do the > necessary changes to the current implementation. > > Regards > > Kevin > > > > > > On Thu, Jul 16, 2015 at 2:59 PM, Handl, Ralf <ralf.ha...@sap.com> wrote: > > 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# > <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:christian.am...@sap.com] > Sent: Mittwoch, 15. Juli 2015 08:44 > To: dev@olingo.apache.org > 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:djkevincr1...@gmail.com] > Sent: Montag, 13. Juli 2015 21:45 > To: Amend, Christian; Christian Amend > Cc: dev@olingo.apache.org > 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 < > djkevincr1...@gmail.com<mailto:djkevincr1...@gmail.com>> 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 <christian.am...@sap.com > <mailto:christian.am...@sap.com>> 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:djkevincr1...@gmail.com<mailto: > djkevincr1...@gmail.com>] > Sent: Sonntag, 12. Juli 2015 20:15 > To: Amend, Christian; Christian Amend > Cc: dev@olingo.apache.org<mailto:dev@olingo.apache.org> > > 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 <christian.am...@sap.com > <mailto:christian.am...@sap.com>> 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:djkevincr1...@gmail.com<mailto: > djkevincr1...@gmail.com>] > Sent: Donnerstag, 9. Juli 2015 21:20 > To: dev@olingo.apache.org<mailto:dev@olingo.apache.org>; 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 <djkevincr1...@gmail.com > <mailto:djkevincr1...@gmail.com>> 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 <christian.am...@sap.com > <mailto:christian.am...@sap.com>> 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:djkevincr1...@gmail.com<mailto: > djkevincr1...@gmail.com>] > Sent: Samstag, 4. Juli 2015 21:49 > To: dev@olingo.apache.org<mailto:dev@olingo.apache.org> > Cc: Amend, Christian; amend.christ...@gmail.com<mailto: > amend.christ...@gmail.com> > > 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 > > > > > > >
