You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@db.apache.org by Oliver Heger <Ol...@t-online.de> on 2004/02/08 20:38:05 UTC
Re: new project question
Hi,
did anyone had a look at that code? I would really appreciate some comments.
Thanks.
Oliver
Oliver Heger wrote:
> Brian,
>
> sorry for the delay. You can now find the actual code at the following
> URL:
>
> http://www.oliver-heger.privat.t-online.de/retrieve.zip
>
> Some short words for explanation:
>
> Heart of the library is the Query class in the parts sub package.
> Together with the other part classes it can be used to construct
> SELECT statements. Some important parts are still missing, e.g. for
> ORDER BY clauses or for generating lists for the IN operator.
>
> In the retrieve package there are some classes and interfaces that
> represent database structures. They have two purposes:
>
> 1. They are used for the mapping facilities. It is possible to address
> tables and columns with logic names, which are then transformed into
> real database names.
> 2. They provide information for automatic generation of join
> conditions. One use case for this library was a highly configurable
> application that allows its user to choose the fields of a table and
> its related tables that should be displayed. For instance imagine an
> application that reads a tasks table for displaying a todo list. It
> allows its users to define the view of their tasks. If a user only
> wants to see fields that are contained in the tasks table, the
> resulting SELECT statement will be quite simple. If he or she is also
> interested in the name and some other attributes of the user who has
> created the task, the user table has to be joined. The library is
> designed that it can automatically detect the involved tables and
> fetch the necessary information about the relations between them
> through the RelationProvider interface. With this information it can
> dynamically create a statement with a join if necessary; the calling
> application need not bother about that.
>
> Of course a couple of unit tests must be added, though the test for
> Query also tests many other classes. Now I am looking forward to your
> comments!
>
> Oliver
Re: new project question
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Thank you, Brian.
The StringBuffer approach is mostly used for performance reasons.
Because a whole SQL statement will likely consist of a bunch of
QueryPart objects I tried to avoid that each object would have to create
a String in its render() method. The actual approach makes it possible
that they all render in the same buffer.
I was also thinking about moving this StringBuffer into the
RenderContext class to get rid off this parameter in many methods. But I
am not sure about that.
Oliver
Brian McCallister schrieb:
> First glance over it is quite complete -- though I am having trouble
> seeing the best ways to use it.
>
> A few questions --
>
> Why render query into the StringBuffer argument instead of returning the
> query string directly as a String? Do you foresee a use case where the
> StringBuffer will need to be modified before or after rendering? This is
> particularly true as you (quite cleanly) abstract out the ability to
> plug different systems sql quirks in.
>
> -Brian
>
Re: new project question
Posted by Oliver Heger <Ol...@t-online.de>.
I put an actualized version of the library online
(http://www.oliver-heger.privat.t-online.de/retrieve.zip). There are a
some more QueryPart classes and more unit tests.
There is also a new class QueryWrapper (not sure if the name fits) that
deals with executing queries: an instance is initialized with a
QueryPart object, and then for this a PreparedStatement can be created.
This statement can then be executed (for execution itself I would like
to use something like commons dbutils).
Oliver
Brian McCallister wrote:
> First glance over it is quite complete -- though I am having trouble
> seeing the best ways to use it.
>
> A few questions --
>
> Why render query into the StringBuffer argument instead of returning
> the query string directly as a String? Do you foresee a use case where
> the StringBuffer will need to be modified before or after rendering?
> This is particularly true as you (quite cleanly) abstract out the
> ability to plug different systems sql quirks in.
>
> -Brian
>
Re: new project question
Posted by Brian McCallister <mc...@forthillcompany.com>.
First glance over it is quite complete -- though I am having trouble
seeing the best ways to use it.
A few questions --
Why render query into the StringBuffer argument instead of returning
the query string directly as a String? Do you foresee a use case where
the StringBuffer will need to be modified before or after rendering?
This is particularly true as you (quite cleanly) abstract out the
ability to plug different systems sql quirks in.
-Brian
On Feb 8, 2004, at 2:38 PM, Oliver Heger wrote:
> Hi,
>
> did anyone had a look at that code? I would really appreciate some
> comments.
>
> Thanks.
> Oliver
>
> Oliver Heger wrote:
>
>> Brian,
>>
>> sorry for the delay. You can now find the actual code at the
>> following URL:
>>
>> http://www.oliver-heger.privat.t-online.de/retrieve.zip
>>
>> Some short words for explanation:
>>
>> Heart of the library is the Query class in the parts sub package.
>> Together with the other part classes it can be used to construct
>> SELECT statements. Some important parts are still missing, e.g. for
>> ORDER BY clauses or for generating lists for the IN operator.
>>
>> In the retrieve package there are some classes and interfaces that
>> represent database structures. They have two purposes:
>>
>> 1. They are used for the mapping facilities. It is possible to
>> address tables and columns with logic names, which are then
>> transformed into real database names.
>> 2. They provide information for automatic generation of join
>> conditions. One use case for this library was a highly configurable
>> application that allows its user to choose the fields of a table and
>> its related tables that should be displayed. For instance imagine an
>> application that reads a tasks table for displaying a todo list. It
>> allows its users to define the view of their tasks. If a user only
>> wants to see fields that are contained in the tasks table, the
>> resulting SELECT statement will be quite simple. If he or she is also
>> interested in the name and some other attributes of the user who has
>> created the task, the user table has to be joined. The library is
>> designed that it can automatically detect the involved tables and
>> fetch the necessary information about the relations between them
>> through the RelationProvider interface. With this information it can
>> dynamically create a statement with a join if necessary; the calling
>> application need not bother about that.
>>
>> Of course a couple of unit tests must be added, though the test for
>> Query also tests many other classes. Now I am looking forward to your
>> comments!
>>
>> Oliver
>
>
>
>
Re: new project question
Posted by Brian McCallister <mc...@forthillcompany.com>.
Woo hoo, I was trying to find your email to download and look at it but
couldn't. Much appreciate the prodding!
-Brian
On Feb 8, 2004, at 2:38 PM, Oliver Heger wrote:
> Hi,
>
> did anyone had a look at that code? I would really appreciate some
> comments.
>
> Thanks.
> Oliver
>
> Oliver Heger wrote:
>
>> Brian,
>>
>> sorry for the delay. You can now find the actual code at the
>> following URL:
>>
>> http://www.oliver-heger.privat.t-online.de/retrieve.zip
>>
>> Some short words for explanation:
>>
>> Heart of the library is the Query class in the parts sub package.
>> Together with the other part classes it can be used to construct
>> SELECT statements. Some important parts are still missing, e.g. for
>> ORDER BY clauses or for generating lists for the IN operator.
>>
>> In the retrieve package there are some classes and interfaces that
>> represent database structures. They have two purposes:
>>
>> 1. They are used for the mapping facilities. It is possible to
>> address tables and columns with logic names, which are then
>> transformed into real database names.
>> 2. They provide information for automatic generation of join
>> conditions. One use case for this library was a highly configurable
>> application that allows its user to choose the fields of a table and
>> its related tables that should be displayed. For instance imagine an
>> application that reads a tasks table for displaying a todo list. It
>> allows its users to define the view of their tasks. If a user only
>> wants to see fields that are contained in the tasks table, the
>> resulting SELECT statement will be quite simple. If he or she is also
>> interested in the name and some other attributes of the user who has
>> created the task, the user table has to be joined. The library is
>> designed that it can automatically detect the involved tables and
>> fetch the necessary information about the relations between them
>> through the RelationProvider interface. With this information it can
>> dynamically create a statement with a join if necessary; the calling
>> application need not bother about that.
>>
>> Of course a couple of unit tests must be added, though the test for
>> Query also tests many other classes. Now I am looking forward to your
>> comments!
>>
>> Oliver
>
>
>
>