Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Martynas Jusevicius <martynas.jusevicius@gmail.com>
Full name Martynas Jusevicius <martynas.jusevicius@gmail.com>
Date 2007-11-09 05:08:20 PST
Message What I mean/think is that we can only dynamically generate unambiguous
and complete SQL if we have classes derived directly from terms in SQL
BNF grammar. In that way generating the query string would be as
simple as flattening the expression object and adding string constants
such as "SELECT" or "WHERE".

This of course could be pretty bloated. And I'm not exactly sure how
it would relate to the Criteria API, at least in its current form. I
guess Criteria API would be some kind of subset of this functionality,
or a convenient wrapper.

For example, I took an excerpt of SELECT statement grammar from
http://savage.net.au​/SQL/sql-92.bnf.html​#query%20specificati​on :

<statement> ::= ... | SELECT <query specification>

<query specification> ::=
 SELECT [ <set quantifier> ] <select list> <table expression>

<table expression> ::=
 <from clause>
 [ <where clause> ]
 [ <group by clause> ]
 [ <having clause> ]

<where clause> ::= WHERE <search condition>

<search condition> ::=
 <boolean term>
| <search condition> OR <boolean term>

This would map to classes like:

class Statement {}
class SelectStatement extends Statement {
    __construct(QuerySpe​cification); }
class QuerySpecification {
    __construct(SelectList, TableExpression)
    __construct(Quantifier, SelectList, TableExpression)
    addQuantifier(Quantifier); }
class SelectList {}
class TableExpression {
    __construct(FormClause);
    __construct(FormClause, WhereClause);
    __construct(FormClause, WhereClause, GroupByClause);
    __construct(FormClause, WhereClause, GroupByClause, HavingClause);
    addWhereClause(WhereClause);
    addGroupByClause(Gro​upByClause);
    addHavingClause(HavingClause); }
class FromClause {}
class WhereClause {
    __construct(SearchCondition); }
class SearchCondition {
    __construct(BooleanTerm);
    __construct(SearchCondition, BooleanTerm); }
class BooleanTerm extends SearchCondition {}

Martynas

On Nov 9, 2007 1:25 PM, Hans Lellelid <hans at velum dot net> wrote:
> Martynas Jusevicius wrote:
> > Hi,
> >
> > I've run into limitations of current Criteria as well. For example,
> > when specifying non-trivial conditions for JOINs.
> >
> > I don't know I there is any background for this, but I have a feeling
> > that Criteria would only be really flexible if based directly on
> > (simplified) grammar of SQL. Still it might turn out too complex :)
>
> Yeah -- the problem with a SQL-looking solution is that we have to
> actually parse strings (not sure if that's what you meant). The other
> Criteria2 experiment was much more closely based on SQL grammer; it was
> just cumbersome for the very simple stuff -- since you had to always set
> up expressions, etc. It was extremely flexible, however. I am going to
> look at the stuff that Ants (and Cameron) have been working with to see
> how far off it is from the implementation I did last year. I think
> there are some similarities.
>
> Also, since this is for 2.0, we may be able to benefit from features
> such as late static binding.
>
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>