Hotchocolate: Error with property that only has getter

[teggno]

Description

My EF core entity class Student has a computed (i.e. only has get but no set) property Foo. When I configure Student in the Query class as IQueryable<Student> decorated with [UseSelection] and then execute a GraphQL query using that property, there is an error. [UseSelection] is the only attribute and if I remove it, the error goes away.
If I change the computed property to be a method instead of a getter, the error also goes away.

Sample code and error stack trace below.

Expected behavior

Get-only properties should be returned also when [UseSelection] is applied.

Environment

• OS: MacOS, .NET Core 3.1
• Version: HotChocolate 10.4.3

Additional context

Sample code

```c#
public class Student
{
public string StudentId { get; set; }

 // Foo as get-only property leads to error
 public string Foo => "Foo";

 // Foo as method works
 // public string GetFoo() => "Foo";

}

public class Query
{
[UseSelection]
public IQueryable Student([Service] SchoolContext dbContext) =>
dbContext.Students;
}

GraphQL query

{
student {
foo
}
}

### Stack Trace

System.ArgumentException: The property 'System.String Foo' has no 'set' accessor (Parameter 'member')
at System.Linq.Expressions.Expression.ValidateSettableFieldOrPropertyMember(MemberInfo member, Type& memberType)
at System.Linq.Expressions.Expression.Bind(MemberInfo member, Expression expression)
at HotChocolate.Types.Selections.SelectionVisitor.LeaveLeaf(IFieldSelection selection)
at HotChocolate.Types.Selections.SelectionVisitorBase.EnterSelection(IFieldSelection selection)
at HotChocolate.Types.Selections.SelectionVisitorBase.VisitSelections(IOutputType outputType, SelectionSetNode selectionSet)
at HotChocolate.Types.Selections.SelectionVisitor.Accept(ObjectField field)
at HotChocolate.Types.Selections.SelectionMiddleware`1.InvokeAsync(IMiddlewareContext context)
at HotChocolate.Execution.ExecutionStrategyBase.ExecuteMiddlewareAsync(ResolverContext resolverContext, IErrorHandler errorHandler)
```

[PascalSenn]

hi @teggno
Yes this is currently indeed a limitation.
Does the method work around work for you?

[teggno]

Hi @PascalSenn and thanks for getting back to me!

Yes, the method work around is fine for me. But the get-only property might be more intuitive I think.

But anyway, thanks for the awesome work!

[PascalSenn]

@teggno
Cool, we will have a look at this some time soon 👍

[XardasLord]

@PascalSenn in our company we're using DDD approach and our domain has only get properties and they read value from backing fields like this:

private string _name;
public string Name => _name;

So to generate a nice SQL query I would like to use [UseSelection] attribute. But I got the same error as @teggno described above.

[TheJayMann]

The way UseSelection works is not compatible with that approach, as it is specifically designed to pick out which fields to return from the query by creating an expression which creates a new object from the existing object copying over only the properties present in the incoming query. Entity Framework Core for SQL Server (and possibly other LINQ providers, but I haven't tested any) are able to translate such a transformation into picking only the necessary fields and joins.
For this to be able to work with currently available technology, the defined types would have to have a constructor parameter for each defined property and UseSelection would have to be configured to know how to deal with immutable types using constructor initialization, and, even then, I'm not completely sure the provider will know how to properly select the correct fields.
When init properties are made available, this should work properly.

[m4ss1m0g]

Like @XardasLord I'm also working with DDD approach and this issue is very frustrating, there are any plan to solve this issue soon maybe in a nightly build ?

Anyway thanks for the greatest work!

[PascalSenn]

Can we close this issue as this is solved in V11 and UseProjections.
Non settable members are not projected as of 11.0.8-preview.8
projecting private properties will only become possible when we start generating custom types.
At the moment we are limited by foos.Select(x => new Foo {EveryThing = x.ThatCanBeProjectedLikeThis}