The problem has been fixed.
Regards revert 863, it has been reverted partially, such revision commited
two little changes:
Index: DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs
===================================================================
--- DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs (revision 862)
+++ DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs (revision 863)
@@ -119,7 +119,7 @@
{
var operandPrecedence =
ExpressionQualifier.GetPrecedence(operand);
string literalOperand = BuildExpression(operand,
queryContext);
- if (operandPrecedence > currentPrecedence)
+ if (operandPrecedence >= currentPrecedence)
literalOperand =
sqlProvider.GetParenthesis(literalOperand);
literalOperands.Add(literalOperand);
}
@@ -277,7 +277,11 @@
var selectClauses = new List<string>();
foreach (var selectExpression in select.GetOperands())
{
- selectClauses.Add(BuildExpression(selectExpression,
queryContext));
+ string expressionString=BuildExpression(selectExpression,
queryContext);
+ if (selectExpression is SelectExpression)
+
selectClauses.Add(sqlProvider.GetParenthesis(expressionString));
+ else
+ selectClauses.Add(expressionString);
}
return sqlProvider.GetSelectClause(selectClauses.ToArray());
}
The first one has been reverted since it introduced the current bug.
In the other hand I disagree on reverting the second code block changes. As
you can see each select operands (or expressions which are projected) are
generated using BuildExpression method independently, even when one of these
operands is another select-expression.
That means that an operand is never compared in priority with the 'parent
select expression' since the comparison happens inside of BuildExpression
method. Usually it is not a problem because a SELECT expression has the
highest priority, but it fails when one of the projected expressions is
another SELET expression.
Finally the changes are:
Index: DbLinq.SqlServer/SqlServerSqlProvider.cs
===================================================================
--- DbLinq.SqlServer/SqlServerSqlProvider.cs (revision 865)
+++ DbLinq.SqlServer/SqlServerSqlProvider.cs (revision 866)
@@ -99,12 +99,6 @@
return GetLiteralMathLog(p, string.Format("{0}",Math.E));
}
-
- protected override string GetLiteralCount(string a)
- {
- return string.Format("COUNT(*)");
- }
-
protected override string GetLiteralStringLength(string a)
{
return string.Format("LEN({0})", a);
@@ -201,5 +195,16 @@
return string.Format("CONVERT({0},{1})", sqlTypeName, a);
}
+ public override string GetColumn(string table, string column)
+ {
+ if (column != "*")
+ return base.GetColumn(table, column);
+ else
+ return "*";
+
+
+ }
+
+
}
}
Index: DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs
===================================================================
--- DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs (revision 865)
+++ DbLinq/Data/Linq/Sugar/Implementation/SqlBuilder.cs (revision 866)
@@ -119,7 +119,7 @@
{
var operandPrecedence =
ExpressionQualifier.GetPrecedence(operand);
string literalOperand = BuildExpression(operand,
queryContext);
- if (operandPrecedence >= currentPrecedence)
+ if (operandPrecedence > currentPrecedence)
literalOperand =
sqlProvider.GetParenthesis(literalOperand);
literalOperands.Add(literalOperand);
}
As you also can see another bug in SqlServersqlProvider ( tablename.*
expression is not supported) was hiding the current problem, it has been
solved too.
Regards.
On Thu, Sep 11, 2008 at 11:51 PM, Pascal Craponne <[EMAIL PROTECTED]> wrote:
> Pablo,
> the changeset 863 added an error with operators priority, adding
> parentheses when not necessary. Now the G2_DeleteTest (and the 2 following)
> fail on Postgres with an invalid command part "COUNT((*))".
> We shouldn't add parenthesis when operator priority is the same, but only
> when the inner operand has a higher priority than the outer one.
> So we need to revert this change, and have two options after this:
> 1. Add a new priority or change "COUNT" priority to something else than
> "Primary" (it does make sense)
> 2. Do some other change-I-have-no-idea-right-now.
> And maybe this would fix the other hack on the same revision.
>
> Can you handle this, Pablo?
>
> --
> Pascal.
>
> jabber/gtalk: [EMAIL PROTECTED]
> msn: [EMAIL PROTECTED]
>
>
> >
>
--
Saludos. Pablo Iñigo Blasco .
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
