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/olingo/odata4/client/api/edm/EdmType.java;h=5a480d72cbbc707696dd358e117468f0f87980fb;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/olingo/odata4/client/api/data/EdmSimpleType.java;h=7d44c376e89b084c6e8563c63317012284278795;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/olingo/odata4/client/api/edm/EnumType.java;h=614c5e1e85a731ae80de56899e7d9d82ae846bf0;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/olingo/odata4/client/api/edm/ComplexType.java;h=929d1b83f4db4c290b0681b7d629b9d0545f33a5;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/olingo/odata4/client/api/edm/EntityType.java;h=37ebc359f0ec36e439b3a8555e23ebaa84506c2e;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/olingo/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/olingo/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=bee2fa5394774b4ea41a71ee433cf5d7366c961c;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=703c0dfa3c23ea66ea88c8fb3875f90962e3a800;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=50dbe0590ff5aa32340eeee5d326844a92f0c91a;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/
