odata / odata.net Goto Github PK

In order to extend ODataUriParser to parse apply specified in OData Extension for Data Aggregation, some classes and methods need to be made public.

1. The ODataQueryOptionParser propery in ODataUriParser.
2. The intern class ODataUriParserConfiguration.
3. The states in ODataQueryOptionParser, like TargetNavigationSource, TargetEdmType, QueryOptions etc.
4. Some internal methods used to parse filter expression.

To Remove:
ODataMessageReader_EntityReferenceLinksInRequestNotAllowed // It is not used any more.

To Modify:
Context_ExecuteExpectsGetOrPost // Now delete is also supported.

Hello,

It looks like ODATAv4 does not support specifying values of enum members as hex values.
For flag-enums, being able to specify them using hex is usually more intuitive,

For example:

<Member Name="All" Value="0xFFFFFFFF" />

Instead of:

<Member Name="All" Value="4294967295" /> 

Reading odata-abnf-construction-rules.txt I see these rules, indicating that hex values are not permitted:

enumMemberValue = int64Value
int64Value = [ sign ] 1*19DIGIT ; numbers in the range from -9223372036854775808 to 9223372036854775807

Looking further at the implementation of the EdmValueParser.TryParseLong, we land in XmlConvert.ToInt64 which, consistent with the rule above, does not parse hex values.

Any plans to support hex values in the future?

We are getting problems with preference header “continue-on-error” in batch handling. As per OData specs, “if this is not specified, then upon encountering an error the service MUST return the error within the batch and stop processing additional requests within the batch”. But we have observed that this is not happening by default.

The WebAPI’s DefaultODataBatchHandler class returns the request collection after parsing, but if we look into individual request then we find that these headers are missing. We could only see it on the top level http request messages’ header, but not on individual batch request item’s header. As of now we have overloaded this class and manually handling this scenario.

From OData V4 spec, a primitive property of a complex property of the entity type is also allowed as the principal/dependent of the referential constraint.
However, ODL doesn't support this.

With following payload, the HomeAddress is serialized into "Address" type, instead of "HomeAddress" type.

{
"@odata.context": "http://bixu-odata-3:9090/OperationService635520379911784964/$metadata#Customers",
"value": [
{
"@odata.id": "http://bixu-odata-3:9090/OperationService635520379911784964/Customers(1)",
"@odata.editLink": "http://bixu-odata-3:9090/OperationService635520379911784964/Customers(1)",
"ID": 1,
"FirstName": "Bob",
"LastName": "Cat",
"Address": {
"@odata.type": "#Microsoft.Test.OData.Services.ODataOperationService.HomeAddress",
"Street": "1 Microsoft Way",
"City": "Tokyo",
"PostalCode": "98052",
"FamilyName": "Cats"
},
"Emails": [
"[email protected]"
],
"Level": "Common"
}
]
}

In ODataLib 6.8.0, the reading of edm:EnumMemberReference constant expression is not supported anymore. However, the TripPin service still uses 6.6.0 and produce edm:EnumMemberReference. This causes a problem for people who tests their client implementation based on 6.8.0 against the TripPin service.

Description

Tests, such as unit tests, are an important part of the development process. It's hard to imagine how a contributor could safely contribute to this project without automated tests to run for validation.

Minimal repro steps

1. git clone https://github.com/OData/odata.net.git
2. Browse cloned code and look for tests to read
3. Attempt to run tests in visual studio

Expected result

Open source code bases should include both product code and relevant test code.

Actual result

odata.net does not contain any test code.

For example:

ODataQueryOptionParser parser = new ODataQueryOptionParser(...,
new Dictionary<string, string> { {"$sElect", "nAme"}});

parser.Resolver = new ODataUriResolver { EnableCaseInsensitive = true};

parser.ParseSelectAndExpand() will failed.

ODataLib used to supports JSON format for payload only,, we can allow read or write payloads with custom format.

• Support resolving custom media types for request and response messages
• Support reading and writing following kinds of payload in custom payload format:
o Feed
o Entry
o Property
o Collection
o Parameter
o Error

Model:

<?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx Version="4.0" xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx">
  <edmx:DataServices>
    <Schema Namespace="NS" xmlns="http://docs.oasis-open.org/odata/ns/edm">
      <ComplexType Name="Name">
        <Property Name="Name" Type="Edm.String" Nullable="true" />
      </ComplexType>
    </Schema>
  </edmx:DataServices>
</edmx:Edmx>

The generated file is like

public partial class Name : global::System.ComponentModel.INotifyPropertyChanged
    {
        /// <summary>
        /// There are no comments for Property Name in the schema.
        /// </summary>
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.OData.Client.Design.T4", "2.0.0")]
        public string Name
        {
            get
            {
                return this._Name;
            }
            set
            {
                this.OnNameChanging(value);
                this._Name = value;
                this.OnNameChanged();
                this.OnPropertyChanged("Name");
            }
        }
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.OData.Client.Design.T4", "2.0.0")]
        private string _Name;

It will report Error : 'Name': member names cannot be the same as their enclosing type

When trying to sort by some of the properties in the People/Trips/PlanItems collection (for example ConfirmationCode, StartsAt, EndsAt, or Duration), it returns an InternalServerError:

http://services.odata.org/V4/TripPinService/People('russellwhyte')/Trips(0)/PlanItems?$orderby=ConfirmationCode%20asc

{
• error: {
• code: "InternalServerError",
• message: "GenericArguments[0], 'System.String', on 'System.Nullable1[T]' violates the constraint of type 'T'.", • innererror: { • message: "GenericArguments[0], 'System.String', on 'System.Nullable1[T]' violates the constraint of type 'T'.",
• type: "System.ArgumentException",
• stacktrace:
" at System.RuntimeType.ValidateGenericArguments(MemberInfo definition, RuntimeType[] genericArguments, Exception e)
at System.RuntimeType.MakeGenericType(Type[] instantiation)
at Microsoft.Test.OData.Services.ODataWCFService.QueryOptionExtensions.ApplyOrderBy(Expression rootExpression, Type entityInstanceType, ODataUriParser uriParser, OrderByClause orderByClause)
at Microsoft.Test.OData.Services.ODataWCFService.QueryContext.ResolveQuery(IODataDataSource dataSource, Int32 level)
at Microsoft.Test.OData.Services.ODataWCFService.Handlers.QueryHandler.Process(IODataRequestMessage requestMessage, IODataResponseMessage responseMessage)
at Microsoft.Test.OData.Services.ODataWCFService.Handlers.RequestHandler.Process(Stream requestStream)
at Microsoft.Test.OData.Services.ODataWCFService.Handlers.RootRequestHandler.Process(Stream requestStream)"
,
• internalexception: {
• message: "GenericArguments[0], 'System.String', on 'System.Nullable`1[T]' violates the constraint of type parameter 'T'.",
• type: "System.TypeLoadException",
• stacktrace:
" at System.RuntimeTypeHandle.Instantiate(RuntimeTypeHandle handle, IntPtr* pInst, Int32 numGenericArgs, ObjectHandleOnStack type)
at System.RuntimeTypeHandle.Instantiate(Type[] inst)
at System.RuntimeType.MakeGenericType(Type[] instantiation)"

}
}
}
}

One scenario is that the client might need to query the service for annotation value change in the model.

Metadata as a service can better resolve this problem.

Within our service we would like to improve the efficiency of deleting an entity that, in addition to it's canonical entity set home, can be accessed by a singleton navigation elsewhere for the scenario where the client does not know (or need to know) the actual Key/s of the entity and hence can't delete it from it's canonical home, but does know the key of the entity that has the singleton navigation to it. In other words we want to delete via the navigation path instead of retrieving it just to determine it's key/s so can then delete from canonical home.

We have no trouble creating the URI with the OData.Client library via a linq expression for the singleton nav ...container.OtherEntities.Where(oe => oe.Id == "blah").Select(oe => oe.TheSingleNavigation) as DataServiceQuery).RequestUri...

But we can't easily send the URI as "container.Execute(requestUri, "DELETE") is explicitly blocked (restricts the verb to not be DELETE).

Can we remove this restriction in the OData.Client ?

We have two entities say Entity1 and Entity2 and these doesn't have any relationship between them. A function that is bound to Collection and it returns the Collection is giving serialization error as below.
"The related entity set could not be found from the OData path. The related entity set is required to serialize the payload."

As per investigation found that the NavigationSource property is set null in ODataPath in this scenario due to which we are getting the error.

Is there any workaround available for this issue?

Exception message: The complex type has no settable properties.

If a complex object has a property that is a collection of abstract complex objects type, then the Serializer does not properly serialize each collection item and also does not annotate the type name for each of the collection item.

Please refer to this question on StackOverflow: http://stackoverflow.com/questions/26250033/character-e-in-odata-v4s-function-string-parameter-is-causing-404-error

please consider the following scenarion

public class Parent
{
    int TotalKPI;
    ICollection<Child> Children;
}

public class Child
{
    int KPI;
}

action does some complex business processing (which is not possible to do on client) that results in creating or updating parent and related children. how to return created/updated parent with all related chidren? now I can either return parent with empty .Children or collection of children

Just as the title suggests. It looks like there's a tiny typo. It only looks like it affects a few source files; it should be simple enough to fix with a quick mechanical refactoring

There are three major types of API versioning recommendations in use today:

1. Path, e.g. .../api/1.0/Customers
2. QueryString, e.g., .../api/Customers?api-version=1.0
3. Header, e.g., x-api-version: 1.0

The .NET client should allow enable a single place to assign a string representation of the API version that should be used, and enable the three strategies mentioned above. Possible client API:

 context.UseQueryStringApiVersioning("api-version", "1.0");
 context.UseHeaderApiVersioning("x-api-version", "1.0");
 context.UsePathApiVersioning("1.0"); // This may not be necessary since this versioning strategy yields different endpoints.

One scenario of it would be that the client can know if to pass an entity or an entity ref for a parameter

6.7

When I try to parse and validate a 4.0 schema that contains an abstract ComplexType I get the following validation error: The complex type 'SampleSchema.C1' is marked as abstract. Abstract complex types are only supported in version 1.1 EDM models.

[OData-Part3] section 9.1.3, Complex Type Attribute Abstract states that:

"A complex type MAY indicate that it cannot be instantiated by providing a Boolean value of true to the Abstract attribute."

Expected: validation must accept abstract complex types as valid.

Example:

<?xml version="1.0" encoding="utf-8" ?>
<edmx:Edmx Version="4.0" xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx">
  <edmx:DataServices>
    <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="SampleSchema" Alias="Self">

      <ComplexType Name="C1" Abstract="true">
      </ComplexType>
      <ComplexType Name="D1" BaseType="SampleSchema.C1">
      </ComplexType>

    </Schema>
  </edmx:DataServices>
</edmx:Edmx>

So that the annotations will be too much in the memory which will cause perf degradation.

Description

There is a version of the OData.OData.Capabilities.V1 vocabulary hosted on Oasis which seems mostly complete: https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/vocabularies/Org.OData.Capabilities.V1.xml

The version used internally seems to be much smaller and incomplete.
https://github.com/OData/odata.net/blob/master/src/Edm/Microsoft/OData/Edm/Vocabularies/CapabilitiesVocabularies.xml#L7

Is there a standard capabilities vocabulary hosted somewhere? Which version should be loaded by EDM implicitly? In the status quo, the latter vocabulary is loaded, but this doesn't seem correct.

Minimal repro steps

1. Instantiate a EDMModel
2. Attempt to add InsertRestriction annotation to the model

Expected result

InsertRestriction can be added without loading additional vocabularies since capabilities are already implicitly referenced in all EDMModels

Actual result

Must explicitly load a copy of the capabilities vocabulary that is more complete. Preferably one similar in completeness to https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/vocabularies/Org.OData.Capabilities.V1.xml

(Moved across from https://aspnetwebstack.codeplex.com/workitem/2095)

Similar to #1884 (the issue asking for returning non set or even abstract entity types from Function), I would benefit from allowing types of non set, abstract, or even contained entity set types be returned from a given navigation.

This would allow having an abstract relationship that could then be identified to concrete set type upon response by the included data context and type fields as required. At the moment the only way to really return a relationship to something is to either:

a) Force all return types of given navigation to have same key scheme and be homed in one entity set from common base (that has the key defined) or

b) Workaround by having multiple navigations for same relationship to various possible set types and then provide meta property to indicate which one should be populated (to avoid client checking all of them to find the relationship);

c) assuming issue #1884 was fixed, then perhaps a bound function to abstract type (but this is not possible now either as formatter can't deduce from type not associated to entity set)

To support this we need a way to have navigation properties in the model that allow not having a navigationPropertyBinding (this is an optional element). Then we need a way to ensure formatter can deduce the set of type being returned (particularly if want to support contained set type, then this would be trickier than via RTTI)

Without support for this and issue #1884 we cannot get the the full benefit of abstract = true types that do not require key and corresponding set to be identified at design time from access point (function or navigation):

http://docs.oasis-open.org/odata/odata/v4.0/os/part3-csdl/odata-v4.0-os-part3-csdl.html#_Toc372793991

13.4 Element edm:NavigationPropertyBinding

If omitted, clients MUST assume that the target entity set or singleton can vary per related entity.

The scenario that is blocked is that:

1. Function calls that returns a single entity can't be included in a batch request
2. Any data request for a single entity can't be included in a batch request

The scenarios that are blocked by this is:

1. Action calls can't be included in a batch request
2. Batch request containing mixed typed of operations can't be sent by the client APIs

When parsing an EDMX we get back an IEdmEntityContainer for the entity container.
However, the interface does not expose the Extends attribute, even thou the underlying CsdlSemanticsEntityContainer has the property available.

Ideally, IEdmEntityContainer would expose the base container as another IEdmEntityContainer, not just a string.

Such as Navigability in Trippin metadata.

So far, ODL supports key and function parameter template. for example:

~/Customers({key}}/Default.MyFunction(p1={p1})

However, ODL should support property and dynamic property template, for example:

~/Customers({key})/{property}
~/Customers({key})/{dynamicProperty}

1. In ODL, support complex value or collection of complex value (primitive value) to be in alias.
2. In Client, use alias to pass complex value in function parameter.

When parsing an EDMX file using EdmxReader we can get a list of EdmError.
The CsdlLocation in these error objects do not have the name of the file where the error originated, although they contain line/column information.

This is not a problem for standalone files, but if the model references other models, it is hard to pinpoint which file contains the error.

Expected: for CsdlLocation to contain file name, in addition to line/column numbers.