Support for projection columns in the model?

I have some logic that I want to reuse between queries and mutations. Simple example would be calculating if an entity can be deleted (which can be a complicated nested query that checks child items).

I could use ResolveWithService to do this and pass in all the items it needs, but that doesn’t feel that reusable in the muation (eg load the item and double check it can be deleted first).

It occurred to me taht the following might be an elegant solution (although keen to hear if you have other ways you normally do this).

public class Order {
   //properties here
   public Expression<Func<ProductOrder, bool>> CanDelete => (x) => x.StatusId == ProductOrderStatusEnum.OnHold;
}

That way we can map it to a Resolve() function in the query, but if I wanted to access it elsewhere the logic is (potentially) executable/translatable to SQL.

research notes

• https://github.com/hazzik/DelegateDecompiler
• https://benjii.me/2018/01/expression-projection-magic-entity-framework-core/

[lukemurray]

That hook would also allow people to add TagWith for #169

[lukemurray]

Was just looking at this as your comment came through.

I played with something like this ages ago to aid reuse

        public static Expression<Func<Task, bool>> ComputedProp_Expression = task => task.IsActive && task.Assignee != null;
        [GraphQLTranslate]
        public bool ComputedProp => IsActive && Assignee != null;

Where EntityGraphQL would look for that expression property to use the expression instead of the computed property.

But I hate that you had to duplicate the logic. Now source generators could create those for you which I think is nice. Could easily provide a extension method to do the translation on a normal ling query when using in mutations etc.

Do agree that it might be outside the scope of the project (although I would like a nice way to reuse some logic).

I have plans for a [GraphQLField] to allow a different way of making fields with arguments etc. So perhaps as part of that need to make sure it works well with some of the other libraries.

Today you could add the Nein Linq fields manually with schema.AddField(...) and a quick win would be a hook on the final execution of the expression where you could than hook in any Decompile() or WithTranslation() type things.