[castor-dev] GSoC 2010 introduction

--001636499f4fe7130104854cbec9
Content-Type: text/plain; charset=ISO-8859-1

Hi folks,
I'll take the chance to introduce myself to the community.

My name is Dennis Butterstein and I'll contribute to castor in the
context of google summer of code over the next few months. I hope to be
able to combine my work on castor with my master's thesis that I'll
start to write soon.

Roughly speaking, my subject will be to refactor loading of entities
from database to be better
maintainable, extendable and more clear.

For those amongst you interested in details I've added a more detailed
description taken from my application for the google summer of code (the
rest of you can ignore this part =) ):

    I started to implement some refactoring to get to know current
    codebase and classes I will need to know to be able to start working
    in GSOC with full force right on time. As stated in jira issue
    castor-2888 there are some refactorings to do to be able to seize
    loading strategies themselves. So the first step will be to adapt
    KeyGenerator implementations to use the new CastorConnection which
    wraps the used PersistenceFactory as well as the used connection
    (java.sql.Connection). By doing so we achieve the possibility to use
    CastorStatement for SQLStatementInsert as well. So
    SQLStatementDelete, SQLStatementUpdate and SQLStatementInsert will
    be constructed in a very similar way and due to that a cleaner
    codebase will arise.

    By now the SQLStatement classes do not only construct the sql
    strings but also the parameter map. To uncouple the order of columns
    in select statements from the order of columns in resultset they
    would have to construct a map of return values as well.

    To be able to seperate those steps namely construction of sql
    string, parameter map and the map of results using the visitor
    pattern could be assistant. Another point is that using the visitor
    pattern will provide more flexibility in constructing query strings
    (e.g. specific visitor could be used for different databases).


    So I think based on these changes it will be possible to start using
    the visitor pattern to build the sql query strings and the parameter
    map at first. This will serve as reference implementation to
    recognize and resolve possible problems.

    After that the subsequent task will be to integrate the visitor
    pattern in the current codebase, start using it and test (not least
    if the entire functionality was preserved).

    Now it will be time to add new functionality. The current select
    class hierarchy has to be extended to support joins and orders. By
    mapping columns of the select-block to names that will be used to
    access values of the resultset the sequence of columns and access to
    values could be decoupled. Subsequently this functionality has to be
    integrated in the visitor pattern.

    At this point SQLStatementLoad can be refactored to use the select
    class hierarchy in order to build the query string, execute the
    statement and extract columns from resultset. Formerly
    SQLStatemenLoad did these tasks on its own.

    After that we can use the select class hierarchy for
    SQLStatementQuery as well. First ParseTreeWalker, OQLQueryImpl and
    QueryResults (and some other classes) will have to be adapted to
    support new class hierarchy. In a first step this will be done for
    oql queries only. Whether to refactor ParseTreeWalker or to use the
    parser created during GSOC 2008 has to be evaluated on time.

    Sql pass through queries will follow but for them we will first
    have to evaluate possibilities how to get results and bind
    parameters in this case.

    Having done these things should make it much easier to adapt loading
    strategies. Based on benchmarks (like the ones in
    cpaptf/src/site/resources/results/) received from a reference
    machine I'll try to enhance loading strategies step by step. I
    thought about making some comparisons to other similar projects
    (e.g. hibernate) if suitable benchmarks exist. We'll have to see
    whether it will be possible to implement an automated decision
    strategy to choose the most efficient loading strategy. Another
    option: we could make the loading strategy configurable as the
    developers should know enough about their project to be able to
    estimate dimensions of relations.
    My work will not contain the implementation of any loading strategy
    or similar. It will only evaluate possibilities and show benchmark
    results to be considered to point out the direction for future work.

Right now I started refactoring SQLStatementUpdate to use CastorConnection.

Well, all that remains to be said is that I'm happy to get that chance
and I'm looking forward* *to work with you.

Here's to successful cooperation!

--001636499f4fe7130104854cbec9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


<div class=3D"moz-text-plain" style=3D"font-family: -moz-fixed; font-size: =
12px;" lang=3D"x-western"><pre>Hi folks,<br>I&#39;ll take the chance to int=
roduce myself to the community.<br><br>My name is Dennis Butterstein and I&=
#39;ll contribute to castor in the<br>
context of google summer of code over the next few months. I hope to be<br>=
able to combine my work on castor with my master&#39;s thesis that I&#39;ll=
<br>start to write soon.<br><br>Roughly speaking, my subject will be to ref=
actor loading of entities<br>
from database to be better<br>maintainable, extendable and more clear.<br><=
br>For those amongst you interested in details I&#39;ve added a more detail=
ed<br>description taken from my application for the google summer of code (=
the<br>
rest of you can ignore this part =3D) ):<br><br>    I started to implement =
some refactoring to get to know current<br>    codebase and classes I will =
need to know to be able to start working<br>    in GSOC with full force rig=
ht on time. As stated in jira issue<br>
    castor-2888 there are some refactorings to do to be able to seize<br>  =
  loading strategies themselves. So the first step will be to adapt<br>    =
KeyGenerator implementations to use the new CastorConnection which<br>    w=
raps the used PersistenceFactory as well as the used connection<br>
    (java.sql.Connection). By doing so we achieve the possibility to use<br=
>    CastorStatement for SQLStatementInsert as well. So<br>    SQLStatement=
Delete, SQLStatementUpdate and SQLStatementInsert will<br>    be constructe=
d in a very similar way and due to that a cleaner<br>
    codebase will arise.<br><br>    By now the SQLStatement classes do not =
only construct the sql<br>    strings but also the parameter map. To uncoup=
le the order of columns<br>    in select statements from the order of colum=
ns in resultset they<br>
    would have to construct a map of return values as well.<br><br>    To b=
e able to seperate those steps namely construction of sql<br>    string, pa=
rameter map and the map of results using the visitor<br>    pattern could b=
e assistant. Another point is that using the visitor<br>
    pattern will provide more flexibility in constructing query strings<br>=
    (e.g. specific visitor could be used for different databases).<br><br> =
   <br>    So I think based on these changes it will be possible to start u=
sing<br>
    the visitor pattern to build the sql query strings and the parameter<br=
>    map at first. This will serve as reference implementation to<br>    re=
cognize and resolve possible problems.<br><br>    After that the subsequent=
 task will be to integrate the visitor<br>
    pattern in the current codebase, start using it and test (not least<br>=
    if the entire functionality was preserved).<br><br>    Now it will be t=
ime to add new functionality. The current select<br>    class hierarchy has=
 to be extended to support joins and orders. By<br>
    mapping columns of the select-block to names that will be used to<br>  =
  access values of the resultset the sequence of columns and access to<br> =
   values could be decoupled. Subsequently this functionality has to be<br>
    integrated in the visitor pattern.<br><br>    At this point SQLStatemen=
tLoad can be refactored to use the select<br>    class hierarchy in order t=
o build the query string, execute the<br>    statement and extract columns =
from resultset. Formerly<br>
    SQLStatemenLoad did these tasks on its own.<br><br>    After that we ca=
n use the select class hierarchy for<br>    SQLStatementQuery as well. Firs=
t ParseTreeWalker, OQLQueryImpl and<br>    QueryResults (and some other cla=
sses) will have to be adapted to<br>
    support new class hierarchy. In a first step this will be done for<br> =
   oql queries only. Whether to refactor ParseTreeWalker or to use the<br> =
   parser created during GSOC 2008 has to be evaluated on time.<br><br>
    Sql pass through queries will follow but for them we will first<br>    =
have to evaluate possibilities how to get results and bind<br>    parameter=
s in this case.<br><br>    Having done these things should make it much eas=
ier to adapt loading<br>
    strategies. Based on benchmarks (like the ones in<br>    cpaptf/src/sit=
e/resources/results/) received from a reference<br>    machine I&#39;ll try=
 to enhance loading strategies step by step. I<br>    thought about making =
some comparisons to other similar projects<br>
    (e.g. hibernate) if suitable benchmarks exist. We&#39;ll have to see<br=
>    whether it will be possible to implement an automated decision<br>    =
strategy to choose the most efficient loading strategy. Another<br>    opti=
on: we could make the loading strategy configurable as the<br>
    developers should know enough about their project to be able to<br>    =
estimate dimensions of relations.<br>    My work will not contain the imple=
mentation of any loading strategy<br>    or similar. It will only evaluate =
possibilities and show benchmark<br>
    results to be considered to point out the direction for future work.<br=
><br>Right now I started refactoring SQLStatementUpdate to use CastorConnec=
tion.<br><br>Well, all that remains to be said is that I&#39;m happy to get=
 that chance<br>
and I&#39;m looking forward* *to work with you.<br><br>Here&#39;s to succes=
sful cooperation!<br><br></pre></div>

--001636499f4fe7130104854cbec9--