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:[email protected]]
Sent: Dienstag, 25. Februar 2014 14:06
To: [email protected]
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/
