Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

How to ignore properties during EDM build #1020

Unanswered
RuiHou105 asked this question in Q&A
Aug 28, 2023 · 1 comments · 2 replies
Discussion options

Hi team,

I know that if we want to ignore properties during EDM model building, we can use the format: for example, auditEvents.Ignore(t => t.activity). In this way the property activity is ignored.

But right now, I am working on providing a common method for service teams to ignore their unused properties. So, in my method, the usage can be: generatedObject.Ignore( t => t.propertyName). My question is: since this is a common method, actually I don't know every class's property name, so how can I write the expression in Ignore method? Or is there any other way to ignore properties?

Thanks,
Rui

You must be logged in to vote

Replies: 1 comment · 2 replies

Comment options

Is there a reason why you could not just have model authors apply [JsonIgnore] (OData 8+) or [IgnoreDataMember] to the properties they want to have excluded? It seems that would solve the problem without having to write any special code on your own.

You must be logged in to vote
2 replies
@RuiHou105
Comment options

Hi @commonsensesoftware thanks for your reply! Here My scenario is: firstly, use the API versioning tool to specify which graph version current controller supports. If current supported version is beta, I am going to ignore nothing; if current supported version is V1.0, I am going to ignore some properties in the startup. So here I can't directly add [JsonIgnore] attribute for properties, since beta version won't ignore any properties.

@commonsensesoftware
Comment options

There are multiple ways to achieve your result, but you'll likely need to create/expose a facility to teams that you can consume. An attribute or interface are good candidates, but that's not the only way.

Let's say you added the attribute:

[AttributeUsage(AttributeTargets.Property)]
public sealed class InPreviewAttribute : Attribute
{
}

Then clients might apply it as:

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

    public string LastName { get; set; }

    [InPreview]
    public string Email { get; set; }
}

I presume you must be using Reflection to enumerate the properties. A rough skeleton might look like:

var builder = new ODataModelConventionBuilder();
var type = typeof(Person);
var entity = builder.AddEntitySet("People", type).EntityType;
var preview = !string.IsNullOrEmpty(apiVersion.Status);

if (preview)
{
    foreach (var property in type.GetRuntimeProperties())
    {
        if (property.GetCustomAttribute<InPreviewAttribute>() is not null)
        {
            entity.RemoveProperty(property);
        }
    }
}

If you know the clients at build-time, then you can use a source generator instead of Reflection. You could also have the clients implement a particular interface or provide some other method to enable them to filter properties. Avoiding Reflection will improve your startup time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.