The old JoinSqlBuilder has been broken since v4.0.52 (after the changes to make all sql expressions parameterized).
I know it’s deprecated, but I have a fair amount of code still relying on it, which would be a big job to refactor.
Can this be fixed?
Here’s an example:
public class TestTable
{
[PrimaryKey]
public int Id {get;set;}
public string Name {get;set;}
}
public class TestChildTable
{
[PrimaryKey]
public int Id {get;set;}
[References(typeof(TestTable))]
public int TestTableId {get;set;}
public string Name {get;set;}
}
var jn = new JoinSqlBuilder<TestTable, TestChildTable>();
jn.Join<TestTable, TestChildTable>(x => x.Id, y => y.TestTableId)
.Where<TestTable>(x => x.Name == "Bob")
.Or<TestChildTable>(x => x.Name == "Bob")
.SelectAll<TestTable>()
.SelectAll<TestChildTable>();
var sql = jn.ToSelectStatement();
/*
SELECT
"TestTable"."Id","TestTable"."Name","TestChildTable"."Id","TestChildTable"."TestTableId","TestChildTable"."Name"
FROM "TestChildTable"
INNER JOIN "TestTable" ON "TestTable"."Id" = "TestChildTable"."TestTableId"
WHERE ("TestTable"."Name" = @0) OR ("TestChildTable"."Name" = @0)
*/
It’s a losing proposition trying to maintain JoinSqlBuilder it was never created, maintained, documented or even used by us and was contributed before the typed SqlExpressions added support for joins and relied on the non-parameterized behavior of Typed SqlExpressions so it no longer works which we’re not going to revert back to. Only thing I’d be able to do would be to collect the params created during the join expression and make it available on the instance but I’d prefer to remove the JoinSqlBuilder class instead since it doesn’t fit with the rest of OrmLite.
But your best path forward is to convert it to use SqlExpressions as JoinSqlBuilder should no longer be necessary. It looks like this query would benefit from our new SelectMulti support which should be able to be rewritten in something like:
However this option (and all dependent functionality) has been removed from next release, so it’s recommended to migrate to using Typed SQL Expressions instead.
Not following where the friction is with SelectMulti as it auto populates your existing table POCO types but this answer shows different ways of accessing custom fields.