ParseExpression - breaks any query that happens to contain the ColumnName

[ColinNg]

ParseExpression(string expression, WhereCondition condition) of SubSonic.Where.Query.cs
returns an incorrect paramValue when the right side of expression also contains columnName

i.e. apply this to "code=BARCODE" and you'll get "BAR" instead of "BARCODE"

[ColinNg]

Anyway I fixed this bug, and will check it into the tree, once I get time to install GitHub tools. Cheers!

[The-Running-Dev]

What's the fix? Comment on here and I can put it in my forked tree and create the pull request.

[ColinNg]

Original line:

string paramValue = Utility.FastReplace(Utility.FastReplace(expression, columnName, String.Empty), comparisonOperator, String.Empty).Trim();

Fix:

// BUG!!! returns an incorrect paramValue when the right side of expression also contains columnName
// i.e. apply this to "code=BARCODE" and you'll get "BAR" instead of "BARCODE" -- literally the "CODE" bug
// string paramValue = Utility.FastReplace(Utility.FastReplace(expression, columnName, String.Empty), comparisonOperator, String.Empty).Trim();
// Begin patch by lululemon athletica.
int comparisonEnd = GetComparisonEndIndex(expression, GetComparisonOperator(comp));
string paramValue = expression.Substring(comparisonEnd, expression.Length - comparisonEnd).Trim();

// End patch by lululemon athletica.

Description:
If the column name (i.e. "code") is contained in the search expression (i.e. searching for "barcode") then the column name is removed from the returned result (i.e. it returns "bar").

[6pac]

This has been fixed and posted to the trunk code. Thanks for your input.

However, it's worth a comment that I don't think this overload of the WHERE method was intended for string comparisons.
You'd expect it to work like:
WHERE("ProductName = 'ProductName771' ")
but if you do that you get the single quotes as part of the comparison expression. So
WHERE("ProductName = ProductName771")
is the correct format (as you correctly use above), but this is pretty unconventional. For clarity you're better off using a different overload, for example
. WHERE("ProductName",Comparison.Like,"%u%")

The only reason you might use the first format is if you are passing the comparison in as a predefined string rather than actually specifying it yourself.