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> 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 J > > > > 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] > *Sent:* Sonntag, 12. Juli 2015 20:15 > *To:* Amend, Christian; Christian Amend > *Cc:* 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> > 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 J > > > > Best Regards, > > Christian > > > > *From:* Kevin Ratnasekera [mailto:djkevincr1...@gmail.com] > *Sent:* Donnerstag, 9. Juli 2015 21:20 > *To:* 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> > 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> > 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] > Sent: Samstag, 4. Juli 2015 21:49 > To: dev@olingo.apache.org > Cc: Amend, Christian; 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 > > > > > > >