Are we talking some kind of PropeSQL... or CreoML?

sorry (had to ask) ;)

On Nov 9, 2007 6:46 PM, 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@cynigram.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::getColumn('test'), Table::getColumn('test2'));
> $statement->setClause(new Where(new Not(new Or(new
> GreaterThan(Table::getColumn('test3'), 1), new
> NotEquals(Table::getColumn('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.jusevicius@gmail.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%20specification :
> >
> > <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(QuerySpecification); }
> > 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(GroupByClause);
> >         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@velum.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@propel.tigris.org
> > > For additional commands, e-mail: dev-help@propel.tigris.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@propel.tigris.org
> > For additional commands, e-mail: dev-help@propel.tigris.org
> >
> >
>
>
> --
> Noah Fontes
> Cynigram Network Administrator
> impl@cynigram.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@propel.tigris.org
> For additional commands, e-mail: dev-help@propel.tigris.org
>
>



--
Cameron Brunner

Want a better web browser?
http://www.spreadfirefox.com/?q=affiliates&id=182780&t=1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@propel.tigris.org
For additional commands, e-mail: dev-help@propel.tigris.org




--
~
Pedram Nimreezi
Senior Programmer / Frameworkologist
mc@majorcomputing.com | pedram@5g.com
--


"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams