Hi Challen, thanks for your suggestions: I was actually more willing to check
(1) whether my understanding, e.g. the concept difference between "old" ODataJClient Edm interfaces and Olingo 4 common Edm interfaces, is correct (2) if so, whether it is immediately necessary to change the client XML Metadata parser accordingly: being not a trivial task, I want to be sure it is needed before committing to it Hope this clarifies. Regards. On 26/02/2014 16:33, Challen He wrote: > Hi Francesco, > > I think cross/circle reference in Edm is inevitable: not only EntityContainer > but also EntityType itself may refer to EntityType, e.g. entity type > 'Employee' has a property of 'Manager' type, and 'Manager' type itself > contains a collection of 'Employee'. So the job of figuring out their > relationships will be taken by user /client / server code if common doesn't > do it. > > A 2-phased solution is: phase1 - parse CSDL xml doc into a set of > intermediate csdl objects (they only have weak reference like the mentioned > String field named 'entityType'), phase2 - use csdl objects to first build > all edm type objects (EdmComplexType, EdmEntityType, EdmEnumType..., need to > handle circle references among them), then these edm type objects are used to > build EntitySet/Container/function/action/annotation term... > > I think we can start with the assumption of no circle reference and later add > support for it, but in the design it looks ok for all Edm interface > definitions to have 'strong type' references like 'EdmEntitySet' -> > 'EdmEntityType', or 'EdmEntityType' -> another 'EdmEntityType' ... > > (though I am not 100% sure but personally I think entity interfaces with > getter only will work, considering that they will be created by > factory/builder) > > Thanks,-Challen > > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: 2014年2月26日 19:14 > To: dev@olingo.incubator.apache.org > Subject: Re: [OLINGO-169] Work in progress > > Hi, > I have spent some more time in comparing the commons-api Edm interfaces and > their client-api counterparts and I am going to try to explain better my > concerns. > > Let's take again the sample below: > > <EntitySet Name="Products" EntityType="ODataDemo.Product"> > <NavigationPropertyBinding > Path="ODataDemo.FeaturedProduct/Advertisement" Target="Advertisements"/> > <NavigationPropertyBinding Path="Categories" Target="Categories"/> > <NavigationPropertyBinding Path="Supplier" Target="Suppliers"/> > <NavigationPropertyBinding Path="ProductDetail" > Target="ProductDetails"/> > </EntitySet> > > Currently, the way odata4-client-core works will barely translate this piece > of information from XML to Java object(s), where an instance of EntitySetImpl > - implementation of EntitySet [9] - has a String field named 'entityType' > with value 'ODataDemo.Product'. > > If you take a look at EdmEntitySet [10] instead, this interface supposes that > an EdmEntitySetImpl will have an EdmEntityType field named 'entityType', > whose value is a reference to an EdmEntityTypeImpl instance for > ODataDemo.Product. > > This fact implies that the metadata XML parser will need, when encountering > the XML attribute > > EntityType="ODataDemo.Product" > > to look at EdmEntityTypeImpl instances built so far during parsing and > associate the one with name 'ODataDemo.Product' to the EdmEntitySetImpl under > construction. > All that where potentially ODataDemo.Product could be not defined in the > current metadata document but in one of referenced metadata documents. > > As you can see, this is a *huge* difference: consider, for example, that the > instances to link to the one under construction could not even be built yet - > see the NavigationPropertyBinding's target above, where "Categories" could be > an EntitySet or a Singleton not yet encountered in the XML document being > parsed. > > Before starting this considerable change effort, I'd like to understand if I > am right in the finding above and also if you think it is worth to change the > way how the client metadata XML parser currently works. > If I am right, in fact, we need either to give up on making the effort to use > the same Edm interfaces client- and server-side or the change described above > must be implemented. > > Another minor issue I have with commons-api Edm interfaces is that they > mostly lack setter methods: is it fine to introduce them? It will make the > XML parser work a little less hard. > > Regards. > > On 25/02/2014 17:16, Amend, Christian wrote: >> 1. Yes using the EdmType hierarchy should work just fine. I Am not quite >> sure what you mean by parsing type expressions. Do you mean that you have a >> Java String and would like to have an EdmPrimitiveType for this? >> >> 2. I see your concern. We had a similar question with V2 when we tried to >> implement a client. We could delete these info objects but would then have >> to provide methods like getEntitySets() (returning a list of EdmEntitySets) >> at the EDM directly. Otherwise how would a client access the entity sets >> without knowing their name first. >> >> 2.) b+c) then lets move the V3 interfaces into commons. >> >> Best Regards, >> Christian >> >> -----Original Message----- >> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >> Sent: Dienstag, 25. Februar 2014 16:10 >> To: dev@olingo.incubator.apache.org >> Subject: Re: [OLINGO-169] Work in progress >> >> On 25/02/2014 14:38, Amend, Christian wrote: >>> Hi Francesco, >>> >>> 1. I don`t quite understand where your concern is there. Could you please >>> clarify? >> Let's put it differently: is there already something for parsing type >> expressions? >> Moreover: is there already something to represent types? I guess that >> EdmType[8]'s hierarchy should fit the job, right? In this case I >> should be able to remove [1][2][3][4][5] and use EdmType descendants. >> >>> 2.) >>> a) The info interfaces are there because there was no way to get a list of >>> all entity sets inside the edm without knowing their name. Also this >>> information is needed for the service document. >> Ok: I am not sure whether the existing interfaces are suitable, from a >> client perspective; consider that client will instantiate the Edm >> interfaces' implementations by parsing the $metadata XML content. >> As an example, please see how to represent something like as >> >> <EntitySet Name="Products" EntityType="ODataDemo.Product"> >> <NavigationPropertyBinding >> Path="ODataDemo.FeaturedProduct/Advertisement" Target="Advertisements"/> >> <NavigationPropertyBinding Path="Categories" Target="Categories"/> >> <NavigationPropertyBinding Path="Supplier" Target="Suppliers"/> >> <NavigationPropertyBinding Path="ProductDetail" >> Target="ProductDetails"/> </EntitySet> >> >> With EntitySet [9] this will result in (please excuse the pseudo-JSON >> representation): >> >> EntitySetImpl { >> name: "Products", >> entityType: "ODataDemo.Product", >> includeInServiceDocument: true, >> navigationPropertyBindings: [ >> NavigationPropertyBindingImpl { >> path: "ODataDemo.FeaturedProduct/Advertisement", >> target: "Advertisements" >> }, >> ... >> ] >> } >> >> i.e. this is more or less the translation of the XML snippet above. >> >> With EdmEntitySet [10] instead the representation is much more >> involved, mostly because metadata is something that is to be built and >> then pushed out as XML, rather than parsed from XML. >> >> Not sure I actually succeeded in expressing my concerns... >> >>> b) No I think the interfaces in [6] should cover all aspects of the EDM. If >>> not this is functionality which has to be added. >>> c) If they can coexist without causing conflicts I would put the V3 >>> interfaces in the commons API. We might not support this on server side >>> from the beginning but a later refactoring would be cumbersome IMHO. >>> Although I am open for other opinions. >> The current client Edm interfaces [7] are available for V3 and V4 >> without conflicts, so there should be no problem on having them in >> odata4-commons-api, without providing server implementations for V3's. >> >> Regards. >> >>> -----Original Message----- >>> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >>> Sent: Dienstag, 25. Februar 2014 14:06 >>> To: dev@olingo.incubator.apache.org >>> Subject: [OLINGO-169] Work in progress >>> >>> Hi all, >>> I have reached a fair stable point for merging ODataJClient's >>> Metadata parsing into olingo-odata4 (in the 'olingo169' GIT branch): >>> now metadata parsing works either for V3 and V4 (few unit tests have >>> been added in olingo-odata4-client-core ). >>> >>> At this point I have two main concerns before considering the work >>> for >>> OLINGO-169 completed (and consequently merge olingo169 into master): >>> >>> 1. types >>> >>> EdmType [1] is an interface (with concrete implementations available >>> for >>> V3 and V4) whose main purpose is parsing type expressions (like as >>> 'Collection(ODataDemo.Product)') into a meaningful representation, e.g. >>> EdmSimpleType [2], EnumType [3], ComplexType [4] or EntityType [5] >>> and also to provide other useful information (is this a collection? >>> does it have a base type?). >>> >>> I am sure that this duplicates something else in odata-olingo4. but I >>> need some guidance about how to replace [1][2][3][4][5]. Also, I >>> suppose that a better location for such items is >>> olingo-odata4-commons-api rather than olingo-odata4-client-api (where they >>> reside ATM). >>> Who would like to volunteer? >>> >>> >>> 2. Edm interfaces >>> >>> olingo-odata4-commons-api holds in [6] the current set of Edm >>> interfaces implemented server-side whilst I have temporarily put the >>> set of Edm interfaces implemented client-side in >>> olingo-odata4-client-api's [7] (and subpackages). >>> >>> Again, I need to understand how to reconcile and consolidate these >>> two sets (into olingo-odata4-commons-api of course), but there are >>> several aspects I don't understand: >>> >>> (a) what is the purpose of *Info interfaces (like as >>> EdmEntitySetInfo)? what's the usage difference with EdmEntitySet? >>> (b) is the set from [6] still to be completed? >>> (c) would it be fine to put in [6] the merge with all interfaces >>> from [7], including V3's or is it better to keep V3's in >>> olingo-odata4-client-api? >>> >>> >>> Thanks for your support. >>> Regards. >>> >>> [1] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/edm/EdmType.java;h=5a480d72cbbc707696dd358e117468 >>> f0f87980fb;hb=olingo169 [2] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/data/EdmSimpleType.java;h=7d44c376e89b084c6e8563c >>> 63317012284278795;hb=olingo169 [3] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/edm/EnumType.java;h=614c5e1e85a731ae80de56899e7d9 >>> d82ae846bf0;hb=olingo169 [4] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/edm/ComplexType.java;h=929d1b83f4db4c290b0681b7d6 >>> 29b9d0545f33a5;hb=olingo169 [5] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/edm/EntityType.java;h=37ebc359f0ec36e439b3a8555e2 >>> 3ebaa84506c2e;hb=olingo169 [6] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=tree;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olin >>> go/odata4/commons/api/edm;h=5735ace09587887d86a9f09c9ffdcd624b97521f; >>> hb=olingo169 [7] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git >>> ;a=tree;f=odata4-lib/odata4-client-api/src/main/java/org/apache/oling >>> o/odata4/client/api/edm;h=31d1e59d5b76ba321b93bd68bda675522f9d1a8c;hb >>> =olingo169 >> [8] >> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git; >> a=blob;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo >> /odata4/commons/api/edm/EdmType.java;h=bee2fa5394774b4ea41a71ee433cf5d >> 7366c961c;hb=olingo169 [9] >> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git; >> a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/olingo/ >> odata4/client/api/edm/v4/EntitySet.java;h=703c0dfa3c23ea66ea88c8fb3875 >> f90962e3a800;hb=olingo169 [10] >> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git; >> a=blob;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo >> /odata4/commons/api/edm/EdmEntitySet.java;h=50dbe0590ff5aa32340eeee5d3 >> 26844a92f0c91a;hb=olingo169 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
