New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Collections with Nullable values for Open/Dynamic properties #635

Closed
ysanghi opened this Issue Jul 14, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@ysanghi
Contributor

ysanghi commented Jul 14, 2016

Short summary (3-5 sentences) describing the issue.
Today, there seems to be no way to specify the type name for oData.Type annotation for collection with nullable values. You can specify type name for collections with a type, but then the collection cannot contain nulls.

Assemblies affected

Which assemblies and versions are known to be affected e.g. OData .Net lib 6.15-beta.
6.15.

Reproduce steps

The simplest set of steps to reproduce the issue. If possible, reference a commit that demonstrates the issue.
Create an open typed entity. Try to post to the entity set and use the following:
{
"Prop@oData.type":"Collection(Edm.String)",
"Prop":["a",null,"b"]
}

Expected result

What would happen if there wasn't a bug.
OData reader and writer would allow the user to add null values in the collections, if they wish to make a nullable collection.

Actual result

What is actually happening.
OData reader and writer are throwing an error specifiying that user cannot give null values for nullable collections, but there is no way to create a nullable collection for open properties.

@Lingxi-Li

This comment has been minimized.

Contributor

Lingxi-Li commented Jul 15, 2016

The spec doesn’t seem to have provided a way to embed the nullability information into a data/instance payload. Since such information is missing, ODL could interpret it in either way, nullable or non-nullable. The latest V7 branch chooses to interpret it as non-nullable. This may rather be an unintentional accident instead of by design. I would say interpreting it as nullable would make more sense here. @LaylaLiu Do you think we can proceed with this? It would be a breaking change, but there should (presumably) be no user code relying on the current behavior.

@Lingxi-Li

This comment has been minimized.

Contributor

Lingxi-Li commented Jul 15, 2016

Some comments on the current behavior. On the writer side, collections of primitive and complex values are written using different approaches.

1) Primitive Case:
Code similar to the following is used:

new ODataProperty
{
    Name = "DynamicPrimitive",
    Value = new ODataCollectionValue
    {
        TypeName = "Collection(Edm.Int64)",
        Items = new Int64?[] { 1, 2, null }
    }
}

In this case, null values are not allowed.

2) Complex Case:
Code similar to the following is used:

() => writer
.Write(new ODataNestedResourceInfo
{
    Name = "DynamicComplex",
    IsCollection = true,
}, () => writer
    .Write(new ODataResourceSet
    {
        TypeName = "Collection(NS.ComplexType)"
    }, () => writer
        .Write((ODataResource)null)
        .Write(new ODataResource
        {
            Properties = new[]
            {
                new ODataProperty { Name = "Prop1", Value = 1 },
                new ODataProperty { Name = "Prop2", Value = 2 }
            }
        })))

In this case, null values are allowed.

@Lingxi-Li

This comment has been minimized.

Contributor

Lingxi-Li commented Jul 15, 2016

  • Fix V7 branch
  • Fix V6 branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment