Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

ParseExpression - breaks any query that happens to contain the ColumnName #5

Closed
ColinNg opened this Issue Oct 14, 2009 · 4 comments

Comments

Projects
None yet
3 participants

ColinNg commented Oct 14, 2009

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 commented Oct 15, 2009

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

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

ColinNg commented Sep 17, 2010

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").

Collaborator

6pac commented Jan 25, 2012

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.

@6pac 6pac closed this Jan 25, 2012

6pac added a commit that referenced this issue Jan 25, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment