通过

[PL] Własny dostawca w LINQ (dla opornych) - cz. 2

  • 项目

Artykuł został rozbity na wiele części, poniżej spis treści:
I. Budowa zapytania
II. Podstawy analizy drzewa wyrażeń
III. Właściwa analiza drzewa wyrażeń
IV. Pobieranie i zwrot danych

Podstawy analizy drzewa wyrażeń

Kontynuując zabawę w własnego dostawcę do Linq chciałem rozwinąć kwestię analizy drzewa wyrażeń i tłumaczenia go na konkretne polecenia (np. SQL). W poprzedniej części wspomniałem o jednej z metod interfejsu IQueryProvider, czyli o BasicQueryProvider.Execute oraz BasicQueryProvider.Execute<T> w naszej implementacji dostawcy.

Stworzony już prosty test rozbudujemy o próbę realnego wykonania zapytania, chociażby poprzez odwołanie do pierwszego znalezionego rekordu:

      Query<Customer> q = new Query<Customer>();

var result = (from c in q
      where c.Age > 10
      select c).First();
Console.WriteLine(result.ToString());

Śledząc wywołania w debugerze (lub rozpoczętą praktyką wyjątków) odkryjemy, że następnymi metodami do poprawnej implementacji są właśnie dwie odmiany Execute() .
Dla ułatwienia na ten moment wersję z szablonem zrobimy tak:

public TRes Execute<TRes>(Expression expression)
{
     return (TRes)this.Execute(expression);
}

I skupimy się na tej drugiej. Nim ją jednak rozdmucham przyjrzyjmy się parametrowi, czyli klasie Expression. Obiekt tej klasy wydaje się mieć niewiele właściwości jak na drzewo wyrażeń:

    public abstract class Expression
    {
        protected Expression(ExpressionType nodeType, Type type);
        public ExpressionType NodeType { get; }
        public Type Type { get; }

//dużo statycznych metod, o których za moment

}

Definicja klasy zawiera o wiele więcej elementów statycznych pomocnych w konstrukcji pełnego drzewa. Nie będę wymieniał wszystkich (parę kliknięć w Visual Studio zrobi to za mnie lepiej) dla przykładu tylko nadmienię parę tak, aby pokazać wam, czego można się spodziewać:

public static BinaryExpression Add(Expression left, Expression right);
public static BinaryExpression And(Expression left, Expression right);
public static MemberAssignment Bind(MemberInfo member, Expression expression);
public static MethodCallExpression Call(Expression instance, MethodInfo method);

Bez tłumaczenia za bardzo, o co chodzi w powyższym można się domyśleć, że z pełną pulą tych metod można sobie spokojnie zagnieździć całkiem skomplikowane drzewo wyrażeń reprezentujące nasze zapytanie. Problem tylko gdzie ta informacja jest skoro obiekt klasy Expression posiada tak niewiele.
Odpowiedź pewnie sami widzicie poniekąd w tym, co powyższe metody zwracają – wyspecjalizowane typy dziedziczące po bazowym Expression. Powyżej mamy BinaryExpression i MethodCallExpression jako przykłady.

Pełne drzewko wygląda tak (źródło: MSDN):

System..::.Object
System.Linq.Expressions..::.Expression
    System.Linq.Expressions..::.BinaryExpression
    System.Linq.Expressions..::.ConditionalExpression
    System.Linq.Expressions..::.ConstantExpression
    System.Linq.Expressions..::.InvocationExpression
    System.Linq.Expressions..::.LambdaExpression
    System.Linq.Expressions..::.MemberExpression
    System.Linq.Expressions..::.MethodCallExpression
    System.Linq.Expressions..::.NewExpression
    System.Linq.Expressions..::.NewArrayExpression
    System.Linq.Expressions..::.MemberInitExpression
    System.Linq.Expressions..::.ListInitExpression
    System.Linq.Expressions..::.ParameterExpression
    System.Linq.Expressions..::.TypeBinaryExpression
    System.Linq.Expressions..::.UnaryExpression

Typów wyrażeń jak widać jest całkiem sporo. Gdybyśmy w naszym Execute sprawdzili, jaki faktyczny typ Expression siedzi w opakowaniu, to na pewno byłby to któryś z powyższych wyspecjalizowanych obiektów.
Zatem spróbujmy przygotować szablon do dalszych testów. Do istniejącej bazy kodu dodałem dwie klasy:

   internal class QueryExecutionPlan
    {
        public QueryExecutionPlan()
        {
            QueryString = "";
            First = false;
            IsValid = false;
        }
        public string QueryString;
        public bool First;
        public bool IsValid;
    }

Ta klasa ma być wynikiem naszego przetwarzania i tłumaczenia drzewa na konkretne zapytanie SQL. Z planem wykonania na razie poza nazwą niewiele tę klasę łączy, ale później będzie to pewien koncept do dalszego rozwoju. Druga klasa, jaką stworzyłem to:

    internal class QueryTranslator<T>
    {
        QueryExecutionPlan queryExecPlan;
        public QueryTranslator()
        { … }

        public QueryExecutionPlan Translate(Expression expression)
        {
            queryExecPlan = new QueryExecutionPlan();
            renderQueryString(expression);
            return queryExecPlan;
        }

        private string renderQueryString(Expression expression) {
            if (expression==null)
                return "";

            switch (expression.NodeType)
            {
                case ExpressionType.Call:
                    //do implementacji
break;
                case ExpressionType.Constant:
                    //do implementacji
break;
                case ExpressionType.Quote:
                    //do implementacji
break;

default:
//dla wszystkich typów, których z jakiegoś powodu nie chcemy wspierać
    throw new NotImplementedException(

@"QueryExecutionPlan does not
support used type of expression: " +

expression.NodeType.ToString());

            }
            return "";
        }
    }

Tutaj na moment się zatrzymam w celu objaśnienia kolejnej nowości – ExpressionType.
Ten numerator zawarty w Expression.NodeType jest kluczowy, jeśli chcemy określić, jaki typ wyrażenia siedzi w środku przekazanego parametru. Powyżej podałem parę nieobsłużonych jeszcze przykładów czyli:
ExpressionType.Call - dla wszelkich funkcji jak na przykład: Join(), Where(), First()
ExpressionType.Constant – dla stałych zwracanych i/lub przekazywanych
ExpressionType.Quote – dla parametrów kontekstowych

Ich jest o wiele więcej i do pary z wszystkimi podtypami Expression omówię je dokładniej w dalszej części. Powyższego switcha na pewno w najbliższej kolejności będziemy mocno rozbudowywać, aby nasze drzewo wyrażeń przekształcić w coś bardziej użytecznego.

Egzekutorem powyższych jest oczywiście IQueryProvider::Execute. W naszym wykonaniu na ten moment wygląda to mniej więcej tak:

   public class BasicQueryProvider : IQueryProvider
    {
  //reszta bez zmian 

public object Execute(Expression expression)
        {
            string rawQueryString = ""; 
            rawQueryString = Translate(expression);
            return getResult(rawQueryString);
        } 
  public string Translate(Expression expression)
        {
            QueryExecutionPlan plan =
new QueryTranslator<Customer>().Translate(expression);
            return plan.QueryString;
        } 
        protected object getResult(string sqlQuery)
        {
            Customer cust = new Customer(); 
            //tu jeszcze nic nie robimy
            //Customer ze względu na bieżacy stan przykładu
            //jest tutaj hardcode'owanym typem zwrotnym 
            return cust;
        }
    }

Aby zachować dobry styl Linq to SQL dodałem jeszcze do Query poniższy kod:

        public override string ToString()
        {
            return provider.Translate(this.Expression);
        }

Dzięki temu przed wykonaniem zawsze w stringu będę mógł sprawdzić, jakie zapytanie stworzyłem poprzez:

var result = (from c in q
      where c.Age > 10
            select c);
Console.WriteLine(result.ToString());

Zwracany result jest w końcu typu Query<Customer>. Na razie zatrzymam się w tym momencie.
W następnej części dokładnie omówię każde wyspecjalizowane *Expression oraz ExpressionType tak, aby powyższy switch nabrał realnego sensu.

Dla zniecierpliwionych dam dobry start do samodzielnej zabawy w postaci:

switch (expression.NodeType)
{
case ExpressionType.Call:                   
  MethodCallExpression callExp =
(MethodCallExpression)expression;
  if (callExp.Method.DeclaringType.Name == "Queryable")
        {
         switch (callExp.Method.Name)
          {
             case "Where":
               queryExecPlan.QueryString =
"SELECT [RESULT] FROM [BODY] WHERE [CONDITIONS] [POSTPARAMS]";
               string body = renderQueryString(callExp.Arguments[0]);
               string conditions = renderQueryString(callExp.Arguments[1]);

               queryExecPlan.QueryString =
queryExecPlan.QueryString.Replace(
"[CONDITIONS]", conditions);
               queryExecPlan.QueryString =
queryExecPlan.QueryString.Replace("[BODY]", body);
             break;
             default:
           throw new NotImplementedException(
                             @"QueryExecutionPlan does not support
                              used type of CALL method: " +
callExp.Method.Name);
           }
        }
       break;
       default:
             throw new NotImplementedException(
"QueryExecutionPlan does not support used type of expression: " +
expression.NodeType.ToString());
}

To chyba dobra podstawa, aby zacząć budować realne zapytanie. Taki stan switcha potraktuję jako podstawę w następnych rozważaniach.

Podsumowując drugą część i podstawy analizy drzewa wyrażeń po uważnej lekturze powinniście zapamiętać:
1) Sama konstrukcja zapytania LINQ w naszym kodzie nie powoduje jeszcze wykonania zapytania. Dopiero odwołanie się do jakiejkolwiek funkcji zwracającej realne rekordy powoduje wykonanie metody IQueryProvider::Execute i zarazem zwrócenie odpowiedniego wyniku.
2) Dla przejrzystości naszego kodu i planu wykonania zapytania (czy w postaci komendy SQL czy jakiejkolwiek własnej interpretacji) warto rozdzielić sam proces tłumaczenia zapytania oraz jego wykonanie i zwrócenie wyników. Może się to przydać w dalszych etapach, np. przy optymalizacji zapytań.
3) Podstawowym typem reprezentującym drzewo wyrażeń jest obiekt typu Expression. W rzeczywistości w środku na ogół siedzi bardziej wyspecjalizowana wersja odpowiadająca za każdy poszczególny element zapytania. Całe drzewo oczywiście badamy iteracyjnie uzależniając od konkretnego typu wyrażenia.
4) Aby dobrze zinterpretować typ wyrażenia należy badać Expression.NodeType, każda z wartości powinna mieć odpowiednie odzwierciedlenie w wyspecjalizowanych typach dziedziczących po Expression

Technorati Tagi: Polish posts,coding,.NET Framework,Linq

Comments