----- Original Message -----
> Hi,
> 
> I would like to start a discussion regarding the $levels implementation
> again. I had a look at the code and found some points where the current
> implementation has some bugs. I would also like to propose changing the
> cycle detection.
> 
> Bug/Improvement:
> If a navigation property has an expand with $levels then only the same
> navigation property must be expanded for the children. 

Is that expected behavior specified in the spec?

>Currently all
> navigation properties of the child are expanded.
> The ExpandSelectHelper getExpandAll and isExpandAll methods are virtually the
> same. We should not need such code duplication.

ok

> ODataMetadata=full does not work with expanded navigation properties and
> $levels.

If that is the case, that is bug, need to treated as such. Not as enhancement 
as you propose.

> The cycle detection runs even if the navigation property is not expanded. I
> can change that to be more efficient.
>
+1
 
> 
> Improvement regarding the cycle detection:
> I would propose to remove the detection based on the OData Entity ID because
> this ID is not mandatory in the OData-Metadata minimal and none case. In
> both cases we now need this ID even if it is not part of the payload but
> only if $levels is specified. 

In my working with OData Entity ID is always required, whether it is to create 
context url or navigational links, trying to figure out equality etc. Letting 
developers submit an entity without its ID just because metadata is none seems 
like not valid argument. The service developer can do little bit more work, but 
can just leave details of OData to framework like Olingo to handle. Otherwise 
every service developer needs to be an OData expert to do even simple stuff. 
But I understand that our thinking may be varied on this point.

>This is also an incompatible change to the
> behavior to the 4.2.0 version which I missed. I would rather use the object
> reference as a base for the comparison or the equals method of the
> ODataEntity object. 

Can you please give a code example? I do not think I follow you. Especially you 
seems to think there is violation of from 4.2.0?

> This way we do not require more information passed to
> the serializer than absolutely necessary.

Why should that matter making serializer more smarter?

Reply via email to