Typed OrmLite projection

ServiceStack.OrmLite
1

Hi, is it possible to support non-anonymous-type projection in OrmLite queries, like the following?

var q = connection.From<MyTable>()
                  .Select(x => new MyDTO // I explicitly use the type so I can get intellisense, compile time validation, and resharper hints
                          {
                             Id = x.Id,
                             Description = x.Code
                          }

It would be so helpful to have a compile-time validation of Select statements, and also have the perception of which fields are used in DTO and which not. I’m aware that I have to cast the result type again in the Db.Select<TResult>(SqlExpression), but this feature would help a lot during development and with tools like Resharper \ Rider.

To be clear, I’m not asking to do something like this:

var q = Db.From<MyTable>().Select(x => new MyDTO {}); // q is now SqlExpression<MyDTO>

While this last thing would be so useful, I’m just askin you to let your Expression parser aware that I wrote an explicit type, without doing nothing more than what it does today. It would not be a breaking changes since no api would change.

2

Please add any feature requests on ServiceStack UserVoice so they can be measured, otherwise they’ll get lost if just posted on the forums.

No only anonymous types are supported, you can use auto properties when the names are the same, e.g:

q.Select(x => new { x.Id, Description = x.Code });

The purpose of the custom select is to specify only which fields you want selected.

The type is only when projecting the results:

var results = db.Select<MyDto>(q);

The typed projection changes the lambda expression definition making it non trivial to support, the redundancy is also confusing as it makes it appear the DTO in the select is the projection when it’s only for selecting which RDBMS fields should be queried.

3

Yes but the redundancies enables the compiler to check what i’m writing, it let me use Rename and Refactor functionalities with my DTO. Part of using an ORM are for this exact reasons.

Please, you should at least try to understand your clients needs.

4

Using an anonymous type already uses the correct property name and type and it’s clearer that only those specific fields are being selected and not all properties of the Type used:

q.Select(x => new { x.Id, x.Code });

Like I said it’s a non-trivial to implement as it changes the captured expression, making it no longer a self-encapsulating expression which the SqlExpression<T> wasn’t designed to support.

5

Using anonymous types does not guarantee any compile-time coherence, nor it helps with the tools I’m talking about.

One thing is to say “it’s non-trivial”, one is to keep saying that your way is the correct one. In both ways it’s not an acceptable answer, because many other free ORMs allows non-anonymous projection.

6

It’s the most ideal for this API which is not projection as you’re insisting, it’s selecting a custom RDBMS field list, projection happens when the returned resultset is mapped to the typed results which happens when using OrmLite APIs execute the captured SqlExpression. This redundancy does add confusion.

In OrmLite selection and projection are decoupled where how results are selected are independent from how they’re mapped. It’s easy to say somethings non trivial when you’re not aware of how it affects the internal c# expression or how disruptive it would be to implement, I’ve already looked into it and determined it doesn’t justify the additional complexity to support.

If you want to request a feature add it on UserVoice, unless it has high demand it’s not going to be considered.