ToUpdateStatement with updateFields param

ServiceStack.OrmLite
1

Hi,

I’m trying to use OrmLite’s ToUpdateStatement overload that accepts updateFields, but it looks like the parameter is ignored.

Expected: when I pass updateFields, the generated SQL should include only those fields in the SET clause.

However, in the current implementation, ToUpdateStatement calls PrepareParameterizedUpdateStatement<T>(dbCmd) without passing updateFields, so it appears the optional parameter is never applied:

public virtual string ToUpdateStatement<T>(IDbCommand dbCmd, T item, ICollection<string> updateFields = null)
{
    dbCmd.Parameters.Clear();
    var dialectProvider = dbCmd.GetDialectProvider();

    // updateFields is not passed here
    dialectProvider.PrepareParameterizedUpdateStatement<T>(dbCmd);

    if (string.IsNullOrEmpty(dbCmd.CommandText))
        return null;

    dialectProvider.SetParameterValues<T>(dbCmd, item);

    return MergeParamsIntoSql(dbCmd.CommandText, ToArray(dbCmd.Parameters));
}

Is this by design (i.e., updateFields is only supported elsewhere), or is this a bug and the call should be something like PrepareParameterizedUpdateStatement<T>(dbCmd, updateFields) (or equivalent) so the generated statement respects the provided field list?

Thanks.

2

Doesn’t look like that’s used anywhere in OrmLite, it instead calls PrepareParameterizedUpdateStatement directly.

Either way, updateFields is now added in this commit and available in the latest pre-release packages.

3

Hi,

thanks for the quick fix — I’ve tested the latest pre-release and can confirm that updateFields is now correctly applied in the SET clause.

However, I noticed a potentially dangerous behavior:
when updateFields is provided, the generated UPDATE statement does not include a WHERE clause for the primary key. This results in an unconstrained UPDATE.

In my case, I’m using ToUpdateStatement to generate UPDATE SQL (for something like bulk update), so I can work around this on my side by appending the WHERE clause manually. Still, from an API safety perspective, this feels unexpected.

Just wanted to report this.

Thanks!