Support declarative ApiVersion over OData entity to build versioned odata model

[chuanboz]

In OData Model Configurations, it mentioned the programing way to build versioned odata model with Ignore method, that's working but not so developer friendly.

The ask here is to support declarative way to annotate OData entity with the ApiVersion attribute, something like this without the need to manually specify PersonModelConfiguration.

public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    [ApiVersion("2.0")]
    public string Email { get; set; }

    [ApiVersion("3.0")]
    public string Phone { get; set; }
}

Or, provide an out-of-box implementation for VesionedEntityModelConfiguration.

[commonsensesoftware]

This is an interesting idea and as far as I can tell plausible. The main catch I see is that you'd have to support a default API version because it cannot be assumed. There could also be an implicit or implied API version at the builder level to minimize the amount of attribution needed.

Something more like:

[ApiVersion("1.0")]
[ApiVersion("2.0")]
[ApiVersion("3.0")]
public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    [MapToApiVersion("2.0")]
    [MapToApiVersion("3.0")]
    public string Email { get; set; }

    [MapToApiVersion("3.0")]
    public string Phone { get; set; }
}

This is technically all possible, but a cursory examination of ODataConventionModelBuilder.cs suggests that the entire builder and its conventions would have to be reimplemented to be API version-aware.

[chuanboz]

We used similar model in Microsoft Intune, with our own FirstSupportedIn attribute as well as our own ODataModelBuilder that understand this versioning, something like below in annotation and from there we could infer the equivalent of your above model.

[FirstSupportedIn("1.0")]
public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    [FirstSupportedIn("2.0")]
    public string Email { get; set; }

    [FirstSupportedIn("3.0")]
    public string Phone { get; set; }
}

In our current code, we always model the version for entity, and use that to model the service version. This is a bit different than your current approach to model the version for controller.

The reason for this approach is, the entity is changing over time each month for each sprint release, and the controller does not change that much from contract perspective, so to keep the backward compatibility we used entity version for service version.

[commonsensesoftware]

Neat! If you still have this builder implementation, I think it should be easy to bridge your implementation. Despite the name, the VersionedODataModelBuilder does not actually extend ODataModelBuilder. You can provide your custom implementation like so:

var modelBuilder = new VersionedODataModelBuilder()
{
    ModelBuilderFactory = () => new IntuneODataModelBuilder(),
    DefaultModelConfiguration = (builder, apiVersion) =>
    {
        var intuneBuilder = (IntuneODataModelBuilder) builder;
        intuneBuilder.ApiVersion = apiVersion;
        intuneBuilder.EntitySet<Computer>( "Computers" );
    },
};
var models = modelBuilder.GetEdmModels();

Or something like that.

[chuanboz]

We had an internal discussion for this, we still want such declarative experience as that's what our develop used to, so want to check if you accept contribution for this and I might have some time next month to submit a general implementation of VesionedEntityModelConfiguration and make it a public supported experience than our home grown private copy.

[commonsensesoftware]

Sounds reasonable to me. I'm sure the community would appreciate that.

[phatcher]

Did this get merged?

[chuanboz]

My priority has changed and haven't had bandwith to do this yet, if someone would like to contribute to this that would be great.

[commonsensesoftware]

I'm cleaning up old issues. While this was a neat idea, it doesn't seem it will ever come to fruition. This could be achieved using some of the techniques listed above or via dependency injection with a custom IModelConfiguration which inspects all the attributes (at least in ASP.NET Core). There really hasn't been any additional demand or interest in this capability so I'll close it out as I have no intention of implementing it myself. Should interest arise again, I'll re-evaluate and/or reopen the issue. Thanks.