svn commit: r1549793 - /incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext

[sk...@apache.org]

Author: sklevenz
Date: Tue Dec 10 09:27:26 2013
New Revision: 1549793

URL: http://svn.apache.org/r1549793
Log:
CMS commit to olingo by sklevenz

Modified:
    incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext

Modified: incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext
URL: http://svn.apache.org/viewvc/incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext?rev=1549793&r1=1549792&r2=1549793&view=diff
==============================================================================
--- incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext (original)
+++ incubator/olingo/site/trunk/content/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.mdtext Tue Dec 10 09:27:26 2013
@@ -118,7 +118,7 @@ The output will be:
 
     Raw: 'a' eq 'b' ------> Whereclause: 'a' = 'b'
 
-The implementation right now can only transform literals which will not be sufficiant if you want to address a property. If an expression contains properties like "EmployeeId" we have to implement the method `visitProperty()`.
+The implementation right now can only transform literals which will not be sufficient if you want to address a property. If an expression contains properties like "EmployeeId" we have to implement the method `visitProperty()`.
 
     @Override
     public Object visitProperty(PropertyExpression propertyExpression, String uriLiteral, EdmTyped edmProperty) {
@@ -235,7 +235,7 @@ Since simple strings cannot show this co
 Test in the sources: JdbcAdvancedStringVisitorTest.class
 
 ##### Example with prepared Statements
-Since string concatenation is very vulnerable against SQL Injection a best practice is to use prepared statements. This can be a tough challenge in this case because not only the value of `EmployeeId` is supplied in the filter expression but the field EmployeeId and the operator as well. Prepared Statements don´t allow statements like `"WHERE ? ? ?"` thus we have to find a way to prepare the prepared statements in advance which can be very complex as the following example will show: The filter expression `"EmployeeId eq '1' and ManagerId eq '2'"` is the same as "ManagerId eq '2' and EmployeeId eq '1'"` but the prepared statement will always look like `"…. WHERE EmployeeId = ? and ManagerId = ?"`.
+Since string concatenation is very vulnerable against SQL Injection a best practice is to use prepared statements. This can be a tough challenge in this case because not only the value of `EmployeeId` is supplied in the filter expression but the field EmployeeId and the operator as well. Prepared Statements don´t allow statements like `"WHERE ? ? ?"` thus we have to find a way to prepare the prepared statements in advance which can be very complex as the following example will show: The filter expression `"EmployeeId eq '1' and ManagerId eq '2'"` is the same as `"ManagerId eq '2' and EmployeeId eq '1'"` but the prepared statement will always look like `"…. WHERE EmployeeId = ? and ManagerId = ?"`.
 
 This tutorial will not solve this problem. Instead it will show a first idea on how to implement such a prepared statement visitor. Again the Where clause will be created using string concatenation. But this time we will replace literals with a "?". These questionmarks can be set in a prepared statement. The methods `visitLiteral` and `visitProperty` will just return their value while the `visitBinary` will contain the logic.