Table Alias Name in Column Description

[tbasallo]

I have a FROM clause that has a join. But my use of NPoco looks like this: .Fetch<CoolestClassEver>("FROM Table1 t1 JOIN Table2 t2...")

Great. If I write the select like so: SELECT t1.Id T1ID, t2.Id T2ID...

I have no issue. But if I try to avoid writing the SELECT part and do this:

public class CoolestClassEver
{
    [Column("t1.Id")]
    public string T1ID {get;set;}
}

It fails because the SELECT statement is written as [t1.Id] instead of [t1].[Id]

Is there anything I missed in the docs that allows me to provide full table aliasing in the column name to allow this?

[billrawlinson]

can you put it as [Column("[t1].[Id]")] Or does that end up doing:

[[t1].[id]] in the result?

[tbasallo]

@schotime I see you closed this, was there a workaround for this or just something not interested in doing? I never found a fix and just wrote all the code out.

*I actually forgot about it and this reminded me

[schotime]

I went on an issue cull and figured anyone who still cared would say, hey, wtf. lol.

[tbasallo]

Lol. That’s funny. My inbox was flooded was closed issues!

Any thoughts on this one? I’ve never looked at the code that handles this piece.

[schotime]

It depends if . is a valid column name? I don't know that answer, but i'm assuming it could be if its within [ ]. Cause then we could split, otherwise we'd have to do a property that says not to escape eg. AlreadyEscaped

[schotime]

It also feels very dodgy, and once you have the alias in there, its not related to the query at all.

[tbasallo]

Its main use case is to allow a model to be used when you're using multiple tables with similar column names without having to write the SELECT and possibly the FROM.

If a full join statement was supported in the table name attribute and aliases supported in the column attribute, you could write out a three table join and all columns in a model and just have to just write the WHERE clause (like we do today in a simple one-table query).

I don't think it's a huge issue and I am not sure of demand. You could solved with writing the SQL or a view, so...if you want to close and revisit in the future, I think it's fine. But it would be nice. Not sure what the v5 roadmap looks like.

[schotime]

https://github.com/schotime/NPoco/issues?q=is%3Aissue+milestone%3Av5+is%3Aclosed

Pretty much done, but it mainly concentrated on records, proper async, missing async methods, interface tidy up