Select<TKey>(Expression<Func<T, TKey>> fields) method question

[CaspianCanuck]

Hi,

This is more of a question than an issue report:

Method Select<TKey>(Expression<Func<T, TKey>> fields) returns SqlExpression<T> but shouldn't it return SqlExpression<TKey> instead?

I.e. if I am doing a projection like .Select(x => new { ID = x.ID, Name = x.Name }) then the result should be an expression of the anonymous type TKey, right? At least that's how it works in Linq.

Can you comment on that please?

P.S. Just as a background: I am working on a common repository interface that can support both NPoco- and EF-based concrete repositories, and this is one of the requirements.

[schotime]

Projections in NPoco are implemented to only select certain columns for an entity.

eg.

public class User {
    public int Id {get;set;}
    public string Name {get;set;}
    public byte[] Avatar {get;set;}
}

For instance, if I had the above User but I didn't want to select the Avatar this time, I could run.

db.FetchBy<User>(sql => sql.Select(x=> new { x.Id, x.Name }))

This is still based on the User object, so that if I then needed a where I could.

db.FetchBy<User>(sql => sql.Select(x=> new { x.Id, x.Name }).Where(x=>x.Avatar == null)

If it returned SqlExpression<TKey> the above statement would not be able to access the avatar property.

Does this make sense?

[CaspianCanuck]

Yep, makes sense. What I've done in my repository class is add the
Linq-to-Objects Select() projection on the enumerated results of the query,
e.g.:

db.FetchBy(sql => sql.Select(x=> new { x.Id, x.Name }).Where(x
=> x.Id == 1).Select(x => new { x.Id, x.Name });

This gives me precisely what I want -- a Linq-like behaviour (so I can keep
my NPoco repo's interface consistent with that of my EF repo), albeit at
the expense of a few extra CPU cycles.

On Wed, Nov 27, 2013 at 7:19 PM, Adam Schroder notifications@github.comwrote:

Projections in NPoco are implemented to only select certain columns for an
entity.

eg.

public class User {
public int Id {get;set;}
public string Name {get;set;}
public byte[] Avatar {get;set;}}

For instance, if I had the above User but I didn't want to select the
Avatar this time, I could run.

db.FetchBy(sql => sql.Select(x=> new { x.Id, x.Name }))

This is still based on the User object, so that if I then needed a where I
could.

db.FetchBy(sql => sql.Select(x=> new { x.Id, x.Name }).Where(x=>x.Avatar == null)

If it returned SqlExpression the above statement would not be able
to access the avatar property.

Does this make sense?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-29431089
.

Tim

P.S. If you have trouble reaching me at tim@askerov.net
tim@askerov.net please
try taskerov@gmail.com taskerov@gmail.com instead.

[schotime]

Cool.
That shouldn't cause too much overhead.
Adam