Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Status and plans criteria 2

propel
Discussion topic

Hide all messages in topic

All messages in topic

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

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2007-11-10 04:49:08 PST
Message No doubt, people should still be able to shoot SQL queries at the
database if they desire.

However, I must admit that I am more and more in favor of something
similar to Doctrine's DQL, since it makes it way easier to formulate
queries than an OO interface (which, on the other hand, shines when it
comes to assembling queries programatically).

Need to ponder that for a bit, really; not sure what you guys think.


David



Am 10.11.2007 um 03:04 schrieb Hans Lellelid:

> I definitely don't want to encourage a PropelSQL, to answer Pedram's
> question :)
>
> I think that we should continue to make it really easy to use SQL for
> those that want to. I think really complex queries are almost always
> going to be simplest in SQL, and we just need to make it possible for
> people to use that if that's what they need. I definitely don't like
> the idea of parsing a "PQL" and creating SQL statements. I know
> Hibernate does this & it works for them, but this just sounds ugly --
> and I don't see a huge benefit over just ordinary SQL. I think the
> Criteria approach -- of providing a class-based system -- makes a lot
> of sense, even in PHP. I really like the way that Criteria enables
> reusable pieces of a query. For example, I love the ability to pass a
> Criteria object into a method and have security criteria injected into
> the object. So nice.
>
> Anyway, so I think an OO solution for query building is an excellent
> complement to SQL.
>
> My 0.02 -
>
> Hans
>
>
> Noah Fontes wrote:
>> 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
>>>
>>>
>>>
>>
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

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

Reply

Author Martynas Jusevicius <martynas dot jusevicius at gmail dot com>
Full name Martynas Jusevicius <martynas dot jusevicius at gmail dot com>
Date 2007-11-10 03:27:39 PST
Message I guess it's the flexibility vs. performance and simplicity trade-off :)
So far Criteria seems to be a subset of this kind of functionality,
and while it stays that way, there will be situations where you want
be able to express some SQL using it.

Martynas

On Nov 9, 2007 7:41 PM, 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.

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

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2007-11-09 18:32:15 PST
Message nods... good, I think maybe a runtime (cough ActiveRecord) no
compile/generation option would be nice to have..
and use the dataobjects if they exist to improve the performance of runtime
discovery.. it's the best of both worlds..


On Nov 9, 2007 9:04 PM, Hans Lellelid <hans at velum dot net> wrote:

> I definitely don't want to encourage a PropelSQL, to answer Pedram's
> question :)
>
> I think that we should continue to make it really easy to use SQL for
> those that want to. I think really complex queries are almost always
> going to be simplest in SQL, and we just need to make it possible for
> people to use that if that's what they need. I definitely don't like
> the idea of parsing a "PQL" and creating SQL statements. I know
> Hibernate does this & it works for them, but this just sounds ugly --
> and I don't see a huge benefit over just ordinary SQL. I think the
> Criteria approach -- of providing a class-based system -- makes a lot
> of sense, even in PHP. I really like the way that Criteria enables
> reusable pieces of a query. For example, I love the ability to pass a
> Criteria object into a method and have security criteria injected into
> the object. So nice.
>
> Anyway, so I think an OO solution for query building is an excellent
> complement to SQL.
>
> My 0.02 -
>
> Hans
>
>
> Noah Fontes wrote:
> > 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
> >>
> >>
> >>
> >
> >
> >
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi
Senior Programmer / Frameworkologist
mc at majorcomputing dot com | pedram at 5g dot com
--


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

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

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-09 18:04:38 PST
Message I definitely don't want to encourage a PropelSQL, to answer Pedram's
question :)

I think that we should continue to make it really easy to use SQL for
those that want to. I think really complex queries are almost always
going to be simplest in SQL, and we just need to make it possible for
people to use that if that's what they need. I definitely don't like
the idea of parsing a "PQL" and creating SQL statements. I know
Hibernate does this & it works for them, but this just sounds ugly --
and I don't see a huge benefit over just ordinary SQL. I think the
Criteria approach -- of providing a class-based system -- makes a lot
of sense, even in PHP. I really like the way that Criteria enables
reusable pieces of a query. For example, I love the ability to pass a
Criteria object into a method and have security criteria injected into
the object. So nice.

Anyway, so I think an OO solution for query building is an excellent
complement to SQL.

My 0.02 -

Hans


Noah Fontes wrote:
> 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
>>
>>
>>
>
>
>

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

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

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2007-11-09 16:02:59 PST
Message 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 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
>
>


--
~
Pedram Nimreezi
Senior Programmer / Frameworkologist
mc at majorcomputing dot com | pedram at 5g dot com
--


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

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

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-11-09 15:46:57 PST
Message 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

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 10:41:40 PST
Message 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

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

Reply

Author Martynas Jusevicius <martynas dot jusevicius at gmail dot com>
Full name Martynas Jusevicius <martynas dot jusevicius at gmail dot 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
>
>

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

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-11-09 04:52:18 PST
Message sync away! +1 for turning resultsets into iterators and only hydrating
results 1 at a time while your at it ;)

On Nov 9, 2007 10:27 PM, Hans Lellelid <hans at velum dot net> wrote:
> Ron Rademaker wrote:
> > Something very different. I got some time reserved next week to do some
> > propel development (such time slots are rare for me), first order of
> > business is gonna be to upgrade our propel 1.3 branch to the latest in
> > propel svn. But I think I'll have some time left to work on a new
> > feature, one I call triggerBackup. I was wondering if this would be a
> > feature people would like in propel and if yes, where should I commit
> > unstable code (I expect version 1 to support only PostreSQL and MySQL).
> > The idea is that you can add triggerBackup='true' in your schema to a
> > <table> node. This would cause propel to generated the table twice, once
> > the way you defined it (primary table), again as <tablename>_backup with
> > extra columns <tablename>_id (foreign key to the primary table) and date
> > (the secondary table). Furthermore, it would create a SQL trigger on the
> > primary table that would add a record with all the information in the
> > deleted / updated record to the secondary table. Hope this short
> > explanation makes sense.
>
> Yeah, it does make sense. I'd like to think about a more general
> solution for this moving forward -- modularized builder components. I
> suppose that trunk would be the place to put this, though trunk has
> grown out-of-date again.
>
> Cameron, have you committed anything to trunk since it was copied form
> 1.3? If not, we may just blow it away and re-sync it w/ 1.3 and then
> new development can happen there -- and we'll have to be better about
> merging in changes to 1.3 :)
>
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> 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

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

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-09 04:27:10 PST
Message Ron Rademaker wrote:
> Something very different. I got some time reserved next week to do some
> propel development (such time slots are rare for me), first order of
> business is gonna be to upgrade our propel 1.3 branch to the latest in
> propel svn. But I think I'll have some time left to work on a new
> feature, one I call triggerBackup. I was wondering if this would be a
> feature people would like in propel and if yes, where should I commit
> unstable code (I expect version 1 to support only PostreSQL and MySQL).
> The idea is that you can add triggerBackup='true' in your schema to a
> <table> node. This would cause propel to generated the table twice, once
> the way you defined it (primary table), again as <tablename>_backup with
> extra columns <tablename>_id (foreign key to the primary table) and date
> (the secondary table). Furthermore, it would create a SQL trigger on the
> primary table that would add a record with all the information in the
> deleted / updated record to the secondary table. Hope this short
> explanation makes sense.

Yeah, it does make sense. I'd like to think about a more general
solution for this moving forward -- modularized builder components. I
suppose that trunk would be the place to put this, though trunk has
grown out-of-date again.

Cameron, have you committed anything to trunk since it was copied form
1.3? If not, we may just blow it away and re-sync it w/ 1.3 and then
new development can happen there -- and we'll have to be better about
merging in changes to 1.3 :)

Hans

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

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-09 04:25:22 PST
Message 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

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

Reply

Author Martynas Jusevicius <martynas dot jusevicius at gmail dot com>
Full name Martynas Jusevicius <martynas dot jusevicius at gmail dot com>
Date 2007-11-09 04:05:20 PST
Message 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 :)

Martynas

On Nov 9, 2007 12:37 PM, Hans Lellelid <hans at velum dot net> wrote:
> Hi Ron,
>
> Ron Rademaker wrote:
> > Hi all,
> >
> > I was wondering what the current plans and status is of criteria 2.
> > There are some guys here working with propel everyday and they're kinda
> > fed up with the current criteria. I think they'll be willing to put in
> > some hours testing and bugfixing criteria 2 as long as they got
> > something that already does some stuff right (and tackles the main
> > problems with current criteria).
>
> Yeah, I'm working right now on closing 1.3 bugs, but I'd like to resume
> work on Criteria2. I agree; current Criteria is lousy. There was a
> Criteria2 implementation that I did (and actually used for a Project)
> that was much more flexible, but the easy stuff got a lot more difficult
> ... so it was scrapped (it's actually in the criteria2-experiment branch
> if you want to look at it).
>
> We'll definitely be targeting 5.3 (w/ namespaces) for propel 2.
>
> As I think about it, I'm not entirely sure that it doesn't make sense to
> have a very core Criteria API and then provide different implementations
> of that which are suited to one type of work or another (e.g. keep
> something that looks like current Criteria for the very basic stuff).
>
> I believe I am going to start this time by coming up with a list of
> example queries that we'd like our Criteria to support -- and then we
> can start showing how it would look in various implementations and get a
> feel for how "easy" these systems will be to use. Since I already have
> a working application with the "criteria2-experiment" version, I can
> provide examples for that one which will illustrate the pros & cons of
> that approach.
>
> Actually, one thing that would be *very* helpful is if you could get
> some feedback from your developers on what they really need in the new
> Criteria -- e.g. which queries they are trying but cannot build in
> current version -- so that we can add those to the list.
>
> Thanks,
> Hans
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

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

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-11-09 04:04:18 PST
Message Would be interesting to see listeners setup so as you could hook this
into various methods... propel 2.1? *grin*

On Nov 9, 2007 10:02 PM, Ron Rademaker <r.rademaker@virt​ualbuilding.nl> wrote:
> Hi Hans,
>
> Hans Lellelid wrote:
> > Actually, one thing that would be *very* helpful is if you could get
> > some feedback from your developers on what they really need in the new
> > Criteria -- e.g. which queries they are trying but cannot build in
> > current version -- so that we can add those to the list.
> >
> > Thanks,
> > Hans
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
> >
> >
>
> I'll send them all an e-mail to tell me their wishes. I think it'll be a
> lot of basic things though, that can actually be accomplished with
> Propel but are though of as being hacky (like manually adding select
> columns for two tables if you want all results when joining two tables)
> or clumsy (like requiring separate criterions to create something like a
> < 5 or a > 10). Anyway, I'll get back to you on this next week.
>
> Something very different. I got some time reserved next week to do some
> propel development (such time slots are rare for me), first order of
> business is gonna be to upgrade our propel 1.3 branch to the latest in
> propel svn. But I think I'll have some time left to work on a new
> feature, one I call triggerBackup. I was wondering if this would be a
> feature people would like in propel and if yes, where should I commit
> unstable code (I expect version 1 to support only PostreSQL and MySQL).
> The idea is that you can add triggerBackup='true' in your schema to a
> <table> node. This would cause propel to generated the table twice, once
> the way you defined it (primary table), again as <tablename>_backup with
> extra columns <tablename>_id (foreign key to the primary table) and date
> (the secondary table). Furthermore, it would create a SQL trigger on the
> primary table that would add a record with all the information in the
> deleted / updated record to the secondary table. Hope this short
> explanation makes sense.
>
> Ron
>
>
> --------------------​--------------------​--------------------​---------
> 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

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

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-09 04:02:16 PST
Message Hi Hans,

Hans Lellelid wrote:
> Actually, one thing that would be *very* helpful is if you could get
> some feedback from your developers on what they really need in the new
> Criteria -- e.g. which queries they are trying but cannot build in
> current version -- so that we can add those to the list.
>
> Thanks,
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>
>

I'll send them all an e-mail to tell me their wishes. I think it'll be a
lot of basic things though, that can actually be accomplished with
Propel but are though of as being hacky (like manually adding select
columns for two tables if you want all results when joining two tables)
or clumsy (like requiring separate criterions to create something like a
< 5 or a > 10). Anyway, I'll get back to you on this next week.

Something very different. I got some time reserved next week to do some
propel development (such time slots are rare for me), first order of
business is gonna be to upgrade our propel 1.3 branch to the latest in
propel svn. But I think I'll have some time left to work on a new
feature, one I call triggerBackup. I was wondering if this would be a
feature people would like in propel and if yes, where should I commit
unstable code (I expect version 1 to support only PostreSQL and MySQL).
The idea is that you can add triggerBackup='true' in your schema to a
<table> node. This would cause propel to generated the table twice, once
the way you defined it (primary table), again as <tablename>_backup with
extra columns <tablename>_id (foreign key to the primary table) and date
(the secondary table). Furthermore, it would create a SQL trigger on the
primary table that would add a record with all the information in the
deleted / updated record to the secondary table. Hope this short
explanation makes sense.

Ron

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

Reply

Author hlellelid
Full name Hans Lellelid
Date 2007-11-09 03:37:42 PST
Message Hi Ron,

Ron Rademaker wrote:
> Hi all,
>
> I was wondering what the current plans and status is of criteria 2.
> There are some guys here working with propel everyday and they're kinda
> fed up with the current criteria. I think they'll be willing to put in
> some hours testing and bugfixing criteria 2 as long as they got
> something that already does some stuff right (and tackles the main
> problems with current criteria).

Yeah, I'm working right now on closing 1.3 bugs, but I'd like to resume
work on Criteria2. I agree; current Criteria is lousy. There was a
Criteria2 implementation that I did (and actually used for a Project)
that was much more flexible, but the easy stuff got a lot more difficult
... so it was scrapped (it's actually in the criteria2-experiment branch
if you want to look at it).

We'll definitely be targeting 5.3 (w/ namespaces) for propel 2.

As I think about it, I'm not entirely sure that it doesn't make sense to
have a very core Criteria API and then provide different implementations
of that which are suited to one type of work or another (e.g. keep
something that looks like current Criteria for the very basic stuff).

I believe I am going to start this time by coming up with a list of
example queries that we'd like our Criteria to support -- and then we
can start showing how it would look in various implementations and get a
feel for how "easy" these systems will be to use. Since I already have
a working application with the "criteria2-experiment" version, I can
provide examples for that one which will illustrate the pros & cons of
that approach.

Actually, one thing that would be *very* helpful is if you could get
some feedback from your developers on what they really need in the new
Criteria -- e.g. which queries they are trying but cannot build in
current version -- so that we can add those to the list.

Thanks,
Hans

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

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-09 03:05:30 PST
Message Thanks for the info, I'll try to remain patient.
Hosting won't be a problem to us as I own my own hosting company :)

Cameron Brunner wrote:
> Considering that php5.3 just changed keywords for how to use
> namespaces, consider propel2/criteria2 in a major state of flux, until
> php is stable nothing will be usable with it. Propel 2 will REQUIRE a
> minimum of php 5.3. Cutting this email a little short since iv been
> drinking but consider propel/criteria2 a while before they are usable
> by the general public and also consider finding hosting once they are
> a pita...
>
> On Nov 9, 2007 6:16 PM, Ron Rademaker <r.rademaker@virt​ualbuilding.nl> wrote:
>
>> Hi all,
>>
>> I was wondering what the current plans and status is of criteria 2.
>> There are some guys here working with propel everyday and they're kinda
>> fed up with the current criteria. I think they'll be willing to put in
>> some hours testing and bugfixing criteria 2 as long as they got
>> something that already does some stuff right (and tackles the main
>> problems with current criteria).
>>
>> Ron
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>>
>
>
>
>

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

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-11-09 02:56:32 PST
Message Considering that php5.3 just changed keywords for how to use
namespaces, consider propel2/criteria2 in a major state of flux, until
php is stable nothing will be usable with it. Propel 2 will REQUIRE a
minimum of php 5.3. Cutting this email a little short since iv been
drinking but consider propel/criteria2 a while before they are usable
by the general public and also consider finding hosting once they are
a pita...

On Nov 9, 2007 6:16 PM, Ron Rademaker <r.rademaker@virt​ualbuilding.nl> wrote:
> Hi all,
>
> I was wondering what the current plans and status is of criteria 2.
> There are some guys here working with propel everyday and they're kinda
> fed up with the current criteria. I think they'll be willing to put in
> some hours testing and bugfixing criteria 2 as long as they got
> something that already does some stuff right (and tackles the main
> problems with current criteria).
>
> Ron
>
> --------------------​--------------------​--------------------​---------
> 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

Status and plans criteria 2

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2007-11-09 00:16:25 PST
Message Hi all,

I was wondering what the current plans and status is of criteria 2.
There are some guys here working with propel everyday and they're kinda
fed up with the current criteria. I think they'll be willing to put in
some hours testing and bugfixing criteria 2 as long as they got
something that already does some stuff right (and tackles the main
problems with current criteria).

Ron
Messages per page: