Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] Status and plans criteria 2

propel
Discussion topic

Back to topic list

Re: [propel-dev] Status and plans criteria 2

Reply

Author Noah Fontes <impl at cynigram dot com>
Full name Noah Fontes <impl at cynigram dot com>
Date 2007-11-09 16:13:40 PST
Message if I get what you're saying (which I think I do), I'm definitely not
disagreeing here -- it would be obvious (I think) to put a system in
place on top of the aforementioned layer that is much more accessible
to the user in general. I'm just not sure if the low-level layer is
the kind of thing that needs to be turned into several hundred
different class definitions, especially in PHP.

In any case we'd have to figure out a system to deal with
database-specific features or deviations from the spec, too. I think
there might be easier ways to handle it than from this approach. Of
course, the contrary might be true, and we might end up with something
that bears striking familiarity to our current approach. Which sucks.

Anyone up for a big planning meeting sometime soon?

(P.S.: If I misunderstood completely, I do apologize. :P)

On 11/9/07, Cameron Brunner <cameron.brunner@​gmail.com> wrote:
> It seems as though in almost everyone's eyes we need a backend format
> that gets turned into the sql for the db then multiple frontends for
> it, am i mistaken here or ? This makes sense to me as well because as
> much as i hate the idea of writing a simplified sql parser i can
> understand how people like to just write human readable queries and
> have the system convert it instead of building it with objects etc at
> times.
>
> On Nov 10, 2007 4:41 AM, Noah Fontes <impl at cynigram dot com> wrote:
> > I had a system very similar to this set up a few months ago following
> > the SQL spec. pretty closely. The problem was that we ended up with
> > things that looked like this:
> >
> > $statement = new Select(Table::getCol​umn('test'), Table::getColumn('test2'));
> > $statement->setClause(new Where(new Not(new Or(new
> > GreaterThan(Table::g​etColumn('test3'), 1), new
> > NotEquals(Table::get​Column('test4'), 'hello')))));
> >
> > ...which is, aside from being hard to write, pretty slow. I'm still
> > throwing the idea around in my head for something comparable,
> > though... I'm not sure if PHP would be the language of choice for such
> > a thing.
> >
> > The other problem with doing things strictly to the spec is that
> > you'll be missing database-specific features (schemas, sequences (are
> > those defined in the spec? I don't think they are), etc.).
> >
> > Definitely a good idea in theory, but if we want to do something like
> > that it needs to be really, really well-thought through.
> >
> >
> > On 11/9/07, Martynas Jusevicius <martynas.jusevic​ius at gmail dot com> wrote:
> > > 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
> > > >
> > > >
> > >
> > > --------------------​--------------------​--------------------​---------
> > > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > > For additional commands, e-mail: dev-help at propel dot tigris dot org
> > >
> > >
> >
> >
> > --
> > Noah Fontes
> > Cynigram Network Administrator
> > impl at cynigram dot com
> >
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
> >
>
>
>
> --
> Cameron Brunner
>
> Want a better web browser?
> http://www.spreadfir​efox.com/?q=affiliat​es&id=182780​&t=1
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
Noah Fontes
Cynigram Network Administrator
impl at cynigram dot com

« Previous message in topic | 15 of 19 | Next message in topic »

Messages

Show all messages in topic

Status and plans criteria 2 Ron Rademaker <r dot rademaker at virtualbuilding dot nl> Ron Rademaker <r dot rademaker at virtualbuilding dot nl> 2007-11-09 00:16:25 PST
     Re: [propel-dev] Status and plans criteria 2 Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2007-11-09 02:56:32 PST
         Re: [propel-dev] Status and plans criteria 2 Ron Rademaker <r dot rademaker at virtualbuilding dot nl> Ron Rademaker <r dot rademaker at virtualbuilding dot nl> 2007-11-09 03:05:30 PST
     Re: [propel-dev] Status and plans criteria 2 hlellelid Hans Lellelid 2007-11-09 03:37:42 PST
         Re: [propel-dev] Status and plans criteria 2 Ron Rademaker <r dot rademaker at virtualbuilding dot nl> Ron Rademaker <r dot rademaker at virtualbuilding dot nl> 2007-11-09 04:02:16 PST
             Re: [propel-dev] Status and plans criteria 2 Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2007-11-09 04:04:18 PST
             Re: [propel-dev] Status and plans criteria 2 hlellelid Hans Lellelid 2007-11-09 04:27:10 PST
                 Re: [propel-dev] Status and plans criteria 2 Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2007-11-09 04:52:18 PST
         Re: [propel-dev] Status and plans criteria 2 Martynas Jusevicius <martynas dot jusevicius at gmail dot com> Martynas Jusevicius <martynas dot jusevicius at gmail dot com> 2007-11-09 04:05:20 PST
             Re: [propel-dev] Status and plans criteria 2 hlellelid Hans Lellelid 2007-11-09 04:25:22 PST
                 Re: [propel-dev] Status and plans criteria 2 Martynas Jusevicius <martynas dot jusevicius at gmail dot com> Martynas Jusevicius <martynas dot jusevicius at gmail dot com> 2007-11-09 05:08:20 PST
                     Re: [propel-dev] Status and plans criteria 2 Noah Fontes <impl at cynigram dot com> Noah Fontes <impl at cynigram dot com> 2007-11-09 10:41:40 PST
                         Re: [propel-dev] Status and plans criteria 2 Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2007-11-09 15:46:57 PST
                             Re: [propel-dev] Status and plans criteria 2 Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2007-11-09 16:02:59 PST
                             Re: [propel-dev] Status and plans criteria 2 Noah Fontes <impl at cynigram dot com> Noah Fontes <impl at cynigram dot com> 2007-11-09 16:13:40 PST
                                 Re: [propel-dev] Status and plans criteria 2 hlellelid Hans Lellelid 2007-11-09 18:04:38 PST
                                     Re: [propel-dev] Status and plans criteria 2 Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2007-11-09 18:32:15 PST
                                     Re: [propel-dev] Status and plans criteria 2 =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2007-11-10 04:49:08 PST
                         Re: [propel-dev] Status and plans criteria 2 Martynas Jusevicius <martynas dot jusevicius at gmail dot com> Martynas Jusevicius <martynas dot jusevicius at gmail dot com> 2007-11-10 03:27:39 PST
Messages per page: