Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] Criteria proposal

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] Criteria proposal

Reply

Author Ants Aasma <ants dot aasma at gmail dot com>
Full name Ants Aasma <ants dot aasma at gmail dot com>
Date 2006-05-31 09:09:12 PDT
Message On 5/31/06, Alan Pinstein <apinstein at mac dot com> wrote:
> > That said, I think we do need a way for people to use custom SQL,
> > because we're never going to account for all the crazy things people
> > want to do.
>
> Indeed... I like the idea of abstracted common functions, but some
> situations *don't* call for DB-independence and require custom SQL.
> We ONLY use postgres, and so we should be able to do postgres-only
> things because for us there is no downside.

I'm not saying that custom SQL should be avoided. Just that there
should be an easy way of doing things the "right way". So those of us
who care about pretty design, can extend the criteria framework with
out custom expressions. Implement them only for the database that we
use, but leave the doors open for implementing them in a database
independent way.

> One idea for the subquery might be to make a SubselectExpr which
> contains a Query instance that can be used as a Criteria. That way
> one would get the Propel benefits of identifier quoting, etc, but
> still be able to do subqueries. This would provide subquery support
> directly in propel without getting to complicated.

That's pretty much what I had in mind. But there should be collection
specific criteria too like has more elements than, all elements equal
or any element is bigger than. These would do the joining and/or
subselecting for the user, making Propel easier to use than doing the
SQL yourself.

Any comments on the idea of providing more complex datatypes with Propel?

Ants Aasma

Re: [propel-dev] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-31 06:21:31 PDT
Message Alan Pinstein wrote:
>> That said, I think we do need a way for people to use custom SQL,
>> because we're never going to account for all the crazy things people
>> want to do.
>
> Indeed... I like the idea of abstracted common functions, but some
> situations *don't* call for DB-independence and require custom SQL. We
> ONLY use postgres, and so we should be able to do postgres-only things
> because for us there is no downside.

Ok -- I think that we'll definitely have support for custom SQL one way
or another. I think abstracting some common functions (especially since
much of that work has already been done) is probably a good move.

>> Yeah, I'm less concerned about subqueries, since they're still only
>> partially supported (AFAIK) in MySQL -- which definitely accounts for a
>> large percentage of the userbase (I'm definitely curious just how large
>> that percentage is). I certainly use subqueries, but at that point I'm
>> just writing custom SQL, so I'm not worried about fitting it into
>> Criteria.
>
> One idea for the subquery might be to make a SubselectExpr which
> contains a Query instance that can be used as a Criteria. That way one
> would get the Propel benefits of identifier quoting, etc, but still be
> able to do subqueries. This would provide subquery support directly in
> propel without getting to complicated.

Yeah, that would be pretty slick -- and shouldn't be too difficult.

Hans

Re: [propel-dev] Criteria proposal

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-05-31 06:05:32 PDT
Message > That said, I think we do need a way for people to use custom SQL,
> because we're never going to account for all the crazy things people
> want to do.

Indeed... I like the idea of abstracted common functions, but some
situations *don't* call for DB-independence and require custom SQL.
We ONLY use postgres, and so we should be able to do postgres-only
things because for us there is no downside.

> Yeah, I'm less concerned about subqueries, since they're still only
> partially supported (AFAIK) in MySQL -- which definitely accounts
> for a
> large percentage of the userbase (I'm definitely curious just how
> large
> that percentage is). I certainly use subqueries, but at that point
> I'm
> just writing custom SQL, so I'm not worried about fitting it into
> Criteria.

One idea for the subquery might be to make a SubselectExpr which
contains a Query instance that can be used as a Criteria. That way
one would get the Propel benefits of identifier quoting, etc, but
still be able to do subqueries. This would provide subquery support
directly in propel without getting to complicated.

Alan

Re: [propel-dev] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-31 05:49:59 PDT
Message Hi -

Ants Aasma wrote:
> Hi,
>
> I looked at the examples you provided. The SqlExpr class seems a bit
> evil to me, as it leaks the database independence abstraction. I don't
> think it should be completely eliminated, but I do think its use
> should be heavily discouraged. Propel should provide a way to abstract
> the more frequently used expressions and provide a way to build plug
> in custom expressions so that the database dependent code goes into a
> well defined place. This will probably bring up the need for the
> criteria interface to be a bit more datatype aware.
>
> So the example
> $c = AuthorPeer::getCriteria();
> $c->add(new SqlExpr("char_length(name) = 4"));
>
> could be something like:
> $c->add(new EqualExpr(StringFiel​d::LengthExpr(Author​Peer::FIRST_NAME), 4));

Yeah, that's not a bad idea. I agree that we want to keep things
abstract. The SqlExpr class is a response to a relatively frequent
request to get custom SQL into Criteria.

Actually, some of this abstraction has already been done, as part of the
DBAdapter system -- e.g. there is a length() method, concat(), etc.
Maybe we just need to document & encourage that approach to query stuff.

That said, I think we do need a way for people to use custom SQL,
because we're never going to account for all the crazy things people
want to do.

> By using this kind of SQL abstraction we could easily add commonly
> used abstract datatypes, such as timeperiod or money, and maybe even
> transparently support the Embedded Value (
> http://www.martinfow​ler.com/eaaCatalog/e​mbeddedValue.html ) pattern.
> This would shift propel a bit into the Data Mapper territory, but
> would make it a lot more suitable as a basis for a cleanly factored
> Domain Model.
>
> I still have to think a bit, how could we fit subqueries into the
> Criteria picture. It would be really sweet, if we could get something
> like this working:
> $c = HotelroomPeer::creat​eCriteria();
> $c->add( HotelroomPeer::RESER​VATIONS()->notAny​(
> ResevationPeer::TIME​PERIOD()->interse​cts( $conference->getTimeperiod()
> ) ) );
> $freeRooms = HotelroomPeer::doSelect( $c );

Yeah, I'm less concerned about subqueries, since they're still only
partially supported (AFAIK) in MySQL -- which definitely accounts for a
large percentage of the userbase (I'm definitely curious just how large
that percentage is). I certainly use subqueries, but at that point I'm
just writing custom SQL, so I'm not worried about fitting it into Criteria.

What I don't want to do is create an extremely heavy & complex Criteria
to account for usage scenarios that we don't want to encourage anyway.
We want Criteria to make writing straightforward queries very easy (and
straightforward queries may have joins). When we start getting into
custom SQL expressions, subqueries, etc., we can provide a bit of
support, but really I think we want to encourage peopel to write SQL, as
that is where portability breaks down anyway.

Hans

Re: [propel-dev] Criteria proposal

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-05-31 05:12:11 PDT
Message What the heck is a fluent interface? I have never heard of such a
thing... Have you got a link? Syntactically, this isn't even valid,
since FIRST_NAME is a class constant.

> $c->add(new EqualExpr(AuthorPeer​::FIRST_NAME()->l​ength(), 4));

Thanks,
Alan

On May 31, 2006, at 7:06 AM, Ants Aasma wrote:

> Hi,
>
> I looked at the examples you provided. The SqlExpr class seems a bit
> evil to me, as it leaks the database independence abstraction. I don't
> think it should be completely eliminated, but I do think its use
> should be heavily discouraged. Propel should provide a way to abstract
> the more frequently used expressions and provide a way to build plug
> in custom expressions so that the database dependent code goes into a
> well defined place. This will probably bring up the need for the
> criteria interface to be a bit more datatype aware.
>
> So the example
> $c = AuthorPeer::getCriteria();
> $c->add(new SqlExpr("char_length(name) = 4"));
>
> could be something like:
> $c->add(new EqualExpr(StringFiel​d::LengthExpr
> (AuthorPeer::FIRST_NAME), 4));
>
> or:
> $c->add(new EqualExpr(AuthorPeer​::FIRST_NAME()->l​ength(), 4));
>
> or going the fluent API way:
> $c->add(AuthorPe​er::FIRST_NAME()-​>length()->equals​(4));
>
> Even with the fluent API, the Criteria design can remain basically the
> same, only adding the convenience factory methods.
>
> By using this kind of SQL abstraction we could easily add commonly
> used abstract datatypes, such as timeperiod or money, and maybe even
> transparently support the Embedded Value (
> http://www.martinfow​ler.com/eaaCatalog/e​mbeddedValue.html ) pattern.
> This would shift propel a bit into the Data Mapper territory, but
> would make it a lot more suitable as a basis for a cleanly factored
> Domain Model.
>
> I still have to think a bit, how could we fit subqueries into the
> Criteria picture. It would be really sweet, if we could get something
> like this working:
> $c = HotelroomPeer::creat​eCriteria();
> $c->add( HotelroomPeer::RESER​VATIONS()->notAny​(
> ResevationPeer::TIME​PERIOD()->interse​cts( $conference->getTimeperiod()
> ) ) );
> $freeRooms = HotelroomPeer::doSelect( $c );
>
> The best part about the fluent interface would be that if we document
> everything appropriately IDE's will autocomplete all of this.
>
> Ants Aasma
>
> PS: Don't think that I'm ignoring you if I don't reply swiftly - I'm
> just having connectivity problems. The germans seem to have
> ridiculously expensive Wifi access. 30mins of wifi in my hotel costs
> the same as two beers from the minibar. Fortunately bundesdruckerei
> has hooked me up with free wiki at the conference center.
>
> --------------------​--------------------​--------------------​---------
> 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] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-31 04:36:50 PDT
Message tamcy wrote:
> Hi devs,
>
> PDO support and Criteria2 are what I'm looking for, so I am really
> happy to see they're coming to Propel :). I have a concern about order
> by clauses and I hope this is on the topic. "Order by" clauses are
> mostly but not neccearily columns, e.g. "order by case when no='4'
> then 1 when no='1' then 2 when no='2' then 3 end, col2" is possible
> (and I just encounter real need to this).
>
> It looks like current Criteria2 is still possible to do so by a, say,
> CustomOrderByColumn class. But this class will then be a decendant of
> QueryColumn, which doesn't "sound right" because a ColumnMap seems
> "too much" for my CustomOrderByColumn class. Also there is no way for
> me to add my own CustomOrderByColumn object to the Query class.

Yeah, I ran into that exact issue; I haven't completely solved it yet,
but I needed the same thing -- a QueryColumn that wasn't tied to a
column map for SELECT statements -- e.g. SELECT COUNT(id) ...

So, we will be rethinking this so that there is a more low-level column
class that doesn't have a ColumnMap. Then SelectColumn and
OrderByColumn could extend this.

We may also use an interface as you suggest -- that would work.

Thanks for the suggestion!

Hans

Re: [propel-dev] Criteria proposal

Reply

Author Ants Aasma <ants dot aasma at gmail dot com>
Full name Ants Aasma <ants dot aasma at gmail dot com>
Date 2006-05-31 04:06:51 PDT
Message Hi,

I looked at the examples you provided. The SqlExpr class seems a bit
evil to me, as it leaks the database independence abstraction. I don't
think it should be completely eliminated, but I do think its use
should be heavily discouraged. Propel should provide a way to abstract
the more frequently used expressions and provide a way to build plug
in custom expressions so that the database dependent code goes into a
well defined place. This will probably bring up the need for the
criteria interface to be a bit more datatype aware.

So the example
$c = AuthorPeer::getCriteria();
$c->add(new SqlExpr("char_length(name) = 4"));

could be something like:
$c->add(new EqualExpr(StringFiel​d::LengthExpr(Author​Peer::FIRST_NAME), 4));

or:
$c->add(new EqualExpr(AuthorPeer​::FIRST_NAME()->l​ength(), 4));

or going the fluent API way:
$c->add(AuthorPe​er::FIRST_NAME()-​>length()->equals​(4));

Even with the fluent API, the Criteria design can remain basically the
same, only adding the convenience factory methods.

By using this kind of SQL abstraction we could easily add commonly
used abstract datatypes, such as timeperiod or money, and maybe even
transparently support the Embedded Value (
http://www.martinfow​ler.com/eaaCatalog/e​mbeddedValue.html ) pattern.
This would shift propel a bit into the Data Mapper territory, but
would make it a lot more suitable as a basis for a cleanly factored
Domain Model.

I still have to think a bit, how could we fit subqueries into the
Criteria picture. It would be really sweet, if we could get something
like this working:
$c = HotelroomPeer::creat​eCriteria();
$c->add( HotelroomPeer::RESER​VATIONS()->notAny​(
ResevationPeer::TIME​PERIOD()->interse​cts( $conference->getTimeperiod()
) ) );
$freeRooms = HotelroomPeer::doSelect( $c );

The best part about the fluent interface would be that if we document
everything appropriately IDE's will autocomplete all of this.

Ants Aasma

PS: Don't think that I'm ignoring you if I don't reply swiftly - I'm
just having connectivity problems. The germans seem to have
ridiculously expensive Wifi access. 30mins of wifi in my hotel costs
the same as two beers from the minibar. Fortunately bundesdruckerei
has hooked me up with free wiki at the conference center.

Re: [propel-dev] Criteria proposal

Reply

Author tamcy <7am dot online at gmail dot com>
Full name tamcy <7am dot online at gmail dot com>
Date 2006-05-31 00:02:11 PDT
Message Hi devs,

PDO support and Criteria2 are what I'm looking for, so I am really
happy to see they're coming to Propel :). I have a concern about order
by clauses and I hope this is on the topic. "Order by" clauses are
mostly but not neccearily columns, e.g. "order by case when no='4'
then 1 when no='1' then 2 when no='2' then 3 end, col2" is possible
(and I just encounter real need to this).

It looks like current Criteria2 is still possible to do so by a, say,
CustomOrderByColumn class. But this class will then be a decendant of
QueryColumn, which doesn't "sound right" because a ColumnMap seems
"too much" for my CustomOrderByColumn class. Also there is no way for
me to add my own CustomOrderByColumn object to the Query class.

Just a thought of implementation, how about:
- There is a OrderBy(for instance) interface
- The OrderByColumn now implements OrderBy extends QueryColumn
- I can have my "class CustomOrderByColumn implements OrderBy"
(actually this CustomOrderByColumn is very general that may even make
it into Propel)
- Current addAscOrderBy and addDescOrderBy should be kept since they
are frequently used
- A new addOrderBy() function that can be used like this:
$query->addOrderBy(new CustomOrderByColumn('case when no='4' then 1
when no='1' then 2 when no='2' then 3 end, col2'));

Tamcy

On 5/31/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi guys -
>
>
> Yeah, I think Criteria makes more sense as a WHERE-clause for the reason
> that Criteria can be nested/related logically. For example:
>
> $c = BookPeer::createCriteria();
> $c->add(new OrExpr(new EqualExpr(....), new GreaterExpr(....)));
>
> $c2 = AuthorPeer::createCriteria();
> $c2->add(new AndExpr(new EqualExpr(...), new InExpr(...)));
>
>
> $c->add($c2);
>
> So, from that example, you could see that if $c2 had
> setLimit()/setOffset​()/setHaving() defined, it would be "lost" when it
> was combined with the $c Criteria. So that was my original thinking
> with moving that to Query -- which is not an object that can be combined
> logically / nested. Hope that makes sense. Now, of course, it could
> just be a matter of choosing a better name for Criteria :)
>
>
> > Also, where does group by go? Does it even need to be handled by
> > Criteria? Are criteria *solely* for selecting data which will be used in
> > Propel-managed objects?
>
> That's also a good question. I don't know, although I think the system
> needs to be a little bit flexible. The reason is that we already use
> some of that flexibility -- for example, in the doCount() methods we
> create a query that doesn't actually hydrate propel result objects.
> That said, I'm not sure we need to support things that Propel probably
> doesn't need -- like aliasing for columns.
>
> Yeah, I think Propel 2.0 can definitely be PHP 5.1 only. I'm not sure
> about 1.3 ... I suppose if we release a 1.3 it can be 5.1 too. I think
> Gentoo considers it stable now, which can be a benchmark of sorts. On
> the other hand, I saw on some list today that CentOS still isn't
> shipping w/ PHP5 :)
>
> I may check in some more code tomorrow. I've completed the
> doUpdate/doDelete()/doInsert() BasePeer methods and have been making
> template changes to use new Criteria. There are a few rough edges
> still, but I think the system holds up fairly well.
>
> ... more to come. Appreciate the feedback & discussion.
>
> 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] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-30 18:43:06 PDT
Message Hi guys -

Alan Pinstein wrote:
>> That is correct, yes. I didn't put up any examples of the Query yet,
>> although you can see one in the ticket comments.
>
> Yeah, that looks nice.
>
>> Basically Query holds stuff that isn't strictly a "criteria". Of
>> course, the line is a little grey when it comes to things like HAVING
>> clause, which is a criteria ... but in those cases, the logic is that
>> Query holds things that don't make sense nested like Criteria.
>
> I wouldn't really consider HAVING a grey area. I think it's only grey
> b/c you defined criteria as the "where" clause, but if you change the
> definition of Criteria to be "result set selectors" which is
> semantically what criteria are anyway, then HAVING fits in nicely.
> Although maybe that means that paging should be moved to criteria as well?
>
> The other option would be to make Criteria strictly "where" clause
> stuff, and put HAVING (and LIMIT/OFFSET) into Query.

Yeah, I think Criteria makes more sense as a WHERE-clause for the reason
that Criteria can be nested/related logically. For example:

   $c = BookPeer::createCriteria();
   $c->add(new OrExpr(new EqualExpr(....), new GreaterExpr(....)));

   $c2 = AuthorPeer::createCriteria();
   $c2->add(new AndExpr(new EqualExpr(...), new InExpr(...)));


   $c->add($c2);

So, from that example, you could see that if $c2 had
setLimit()/setOffset​()/setHaving() defined, it would be "lost" when it
was combined with the $c Criteria. So that was my original thinking
with moving that to Query -- which is not an object that can be combined
logically / nested. Hope that makes sense. Now, of course, it could
just be a matter of choosing a better name for Criteria :)


> Also, where does group by go? Does it even need to be handled by
> Criteria? Are criteria *solely* for selecting data which will be used in
> Propel-managed objects?

That's also a good question. I don't know, although I think the system
needs to be a little bit flexible. The reason is that we already use
some of that flexibility -- for example, in the doCount() methods we
create a query that doesn't actually hydrate propel result objects.
That said, I'm not sure we need to support things that Propel probably
doesn't need -- like aliasing for columns.

Yeah, I think Propel 2.0 can definitely be PHP 5.1 only. I'm not sure
about 1.3 ... I suppose if we release a 1.3 it can be 5.1 too. I think
Gentoo considers it stable now, which can be a benchmark of sorts. On
the other hand, I saw on some list today that CentOS still isn't
shipping w/ PHP5 :)

I may check in some more code tomorrow. I've completed the
doUpdate/doDelete()/doInsert() BasePeer methods and have been making
template changes to use new Criteria. There are a few rough edges
still, but I think the system holds up fairly well.

... more to come. Appreciate the feedback & discussion.

Hans

Re: [propel-dev] Criteria proposal

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-05-30 17:46:52 PDT
Message On 5/31/06, Alan Pinstein <apinstein at mac dot com> wrote:
> > That is correct, yes. I didn't put up any examples of the Query yet,
> > although you can see one in the ticket comments.
>
> Yeah, that looks nice.
>
> > Basically Query holds stuff that isn't strictly a "criteria". Of
> > course, the line is a little grey when it comes to things like HAVING
> > clause, which is a criteria ... but in those cases, the logic is that
> > Query holds things that don't make sense nested like Criteria.
>
> I wouldn't really consider HAVING a grey area. I think it's only grey
> b/c you defined criteria as the "where" clause, but if you change the
> definition of Criteria to be "result set selectors" which is
> semantically what criteria are anyway, then HAVING fits in nicely.
> Although maybe that means that paging should be moved to criteria as
> well?
>
> The other option would be to make Criteria strictly "where" clause
> stuff, and put HAVING (and LIMIT/OFFSET) into Query.
>
> Also, where does group by go? Does it even need to be handled by
> Criteria? Are criteria *solely* for selecting data which will be used
> in Propel-managed objects?
>
> I think that I am fine conceptually with Criteria / Query being more
> of a "Propel object selector" system than a general way to create
> queries, but others may certainly disagree. We just need to pick
> either direction so that we can state it in the spec. May require
> some further discussion and empirical data from Propel users.

Personally i quite like the idea that criteria can handle group by,
its a lot cleaner and also removes problems of identifier quoting on
the group by clause

eg:
$c = new Criteria();
// category_id
$c->addSelectColumn ( BackgroundPeer::CATEGORY_ID );
// COUNT(blah)
$c->addSelectColumn ( BackgroundPeer::COUNT );
// GROUP BY category_id
$c->addGroupByColumn ( BackgroundPeer::CATEGORY_ID );

is actual code i use so removing group by from it would be frustrating
for me personally.


Cameron

Re: [propel-dev] Criteria proposal

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-05-30 17:34:24 PDT
Message > That is correct, yes. I didn't put up any examples of the Query yet,
> although you can see one in the ticket comments.

Yeah, that looks nice.

> Basically Query holds stuff that isn't strictly a "criteria". Of
> course, the line is a little grey when it comes to things like HAVING
> clause, which is a criteria ... but in those cases, the logic is that
> Query holds things that don't make sense nested like Criteria.

I wouldn't really consider HAVING a grey area. I think it's only grey
b/c you defined criteria as the "where" clause, but if you change the
definition of Criteria to be "result set selectors" which is
semantically what criteria are anyway, then HAVING fits in nicely.
Although maybe that means that paging should be moved to criteria as
well?

The other option would be to make Criteria strictly "where" clause
stuff, and put HAVING (and LIMIT/OFFSET) into Query.

Also, where does group by go? Does it even need to be handled by
Criteria? Are criteria *solely* for selecting data which will be used
in Propel-managed objects?

I think that I am fine conceptually with Criteria / Query being more
of a "Propel object selector" system than a general way to create
queries, but others may certainly disagree. We just need to pick
either direction so that we can state it in the spec. May require
some further discussion and empirical data from Propel users.

> P.S. I'd like to add the spl_autoload stuff in 2.0; I think you had
> some
> patches? We can also put this in a 1.3 if you like, but I have hopes
> that 2.0 is not going to be such a long development cycle as you
> think;
> I intend to use Propel 2.0 in an app I'm developing to be deployed by
> the end of the summer.

I do still have those... I am using them in my production
environment. I have attached them. Of course they also factor out the
Criteria includes so that may have to change if 2.0 is on PDO...
Attachments

Re: [propel-dev] Criteria proposal

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-05-30 17:09:25 PDT
Message Just throwing my hat into the ring with a question here, will there be
any way to do identifier quoting on custom sql and what thoughts did
you have on identifier quoting with the new criteria setup? when i was
looking into it last it seemed the best method (most compatible) was
to pass around objects that had the info in it

Also as for spl_autoload, thats php5.1 not 5.0, you would need to bump
the version requirements for propel 1.3 if you wanted to commit those
so consider it carefully beforehand (im all for it being in 2.0 tho),
that said tho, this is quoting from
http://www.zend.com/​zend/week/week286.ph​p

RIP: PHP_5_0

Sönke Rümpler wrote to internals@ wondering what the status of the PHP
5.0 series is these days. His assumption was that the branch is no
longer being updated; was he correct in believing that he should
upgrade to PHP 5.1.*?

Andi Gutmans confirmed that PHP 5.0.* development has now been
discontinued in favour of the PHP_5_1 branch, and advised Sönke to go
with the 5.1 series.

Short version: It's official.

so we can follow the official 'use 5.1' line that they are already
taking easily enough...


Cameron

On 5/31/06, Hans Lellelid <hans at velum dot net> wrote:
> That is correct, yes. I didn't put up any examples of the Query yet,
> although you can see one in the ticket comments.
>
> Basically Query holds stuff that isn't strictly a "criteria". Of
> course, the line is a little grey when it comes to things like HAVING
> clause, which is a criteria ... but in those cases, the logic is that
> Query holds things that don't make sense nested like Criteria.
>
> I'm implementing the doInsert(), doUpdate(), and doDelete() now. When
> I'm done I may check in that code, but that will mean that old Criteria
> will cease to exist (or at least be usable) in trunk. That may be fine.
>
> I did some preliminary benchmarking and found the new Criteria system to
> be a bit quicker, but really there's not a lot of difference. The new
> system is more logically complex & involves many more method calls /
> object creation -- but then involves a lot less string parsing and code
> in general. These seem to even out in the end, making for only a few
> hundred microsecs improvement in the new implementation.
>
> (I haven't done any benchmarking of overall query performance in 1.2
> branch vs. trunk.)
>
> Hans
>
> P.S. I'd like to add the spl_autoload stuff in 2.0; I think you had some
> patches? We can also put this in a 1.3 if you like, but I have hopes
> that 2.0 is not going to be such a long development cycle as you think;
> I intend to use Propel 2.0 in an app I'm developing to be deployed by
> the end of the summer.
>
> Alan Pinstein wrote:
> > Nice... looking good.
> >
> > So I suppose that Criteria2 needs to go hand-in-hand with Query as well?
> > And that's where improved Join support, sorting, pagination, etc. will go?
> >
> > Alan
> >
> > On May 30, 2006, at 9:24 AM, Hans Lellelid wrote:
> >
> >> Hi Alan,
> >>
> >> I added some more examples to the wiki page.
> >>
> >> -H
> >>
> >> Alan Pinstein wrote:
> >>> Thanks for kicking this off.
> >>>
> >>> I posted something about a year ago (I can't believe I've been using
> >>> Propel for a year!) and I think most of the comments are still relevant:
> >>>
> >>> http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609
> >>>
> >>> You've got a good start, but as you've mentioned, Criteria is currently
> >>> good at simple things but not a complex ones. Yet your examples on the
> >>> planning page are still relatively simply queries.
> >>>
> >>> I think we should think about the interface for the more complicated
> >>> parts as well:
> >>>
> >>> 1) Joining and table aliasing
> >>> 2) Sorting and pagination
> >>>
> >>> Can you explain the Query* classes more?
> >>>
> >>> I'd be happy to contribute time to flushing out design over the next few
> >>> weeks.
> >>>
> >>> Thanks!
> >>>
> >>> Alan
> >>>
> >>> On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:
> >>>
> >>>> Hi -
> >>>>
> >>>> I put together a rough proposal/strategy for a new Criteria API on the
> >>>> wiki page.
> >>>>
> >>>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
> >>>>
> >>>> The implementation is still only very loosely conceptual and it doesn't
> >>>> address all the functionality of the current system yet. It does,
> >>>> however, provide a more consistent & somewhat more intuitive system
> >>>> (both to use & to develop, in my opinion). The design is based loosely
> >>>> on the Hibernate Criteria API and the way that the logical expressions
> >>>> are handled by Phing's Condition system.
> >>>>
> >>>> I think it's a good starting point, and would be interested in any
> >>>> comments at this point.
> >>>>
> >>>> Hans

Re: [propel-dev] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-30 07:48:57 PDT
Message That is correct, yes. I didn't put up any examples of the Query yet,
although you can see one in the ticket comments.

Basically Query holds stuff that isn't strictly a "criteria". Of
course, the line is a little grey when it comes to things like HAVING
clause, which is a criteria ... but in those cases, the logic is that
Query holds things that don't make sense nested like Criteria.

I'm implementing the doInsert(), doUpdate(), and doDelete() now. When
I'm done I may check in that code, but that will mean that old Criteria
will cease to exist (or at least be usable) in trunk. That may be fine.

I did some preliminary benchmarking and found the new Criteria system to
be a bit quicker, but really there's not a lot of difference. The new
system is more logically complex & involves many more method calls /
object creation -- but then involves a lot less string parsing and code
in general. These seem to even out in the end, making for only a few
hundred microsecs improvement in the new implementation.

(I haven't done any benchmarking of overall query performance in 1.2
branch vs. trunk.)

Hans

P.S. I'd like to add the spl_autoload stuff in 2.0; I think you had some
patches? We can also put this in a 1.3 if you like, but I have hopes
that 2.0 is not going to be such a long development cycle as you think;
I intend to use Propel 2.0 in an app I'm developing to be deployed by
the end of the summer.

Alan Pinstein wrote:
> Nice... looking good.
>
> So I suppose that Criteria2 needs to go hand-in-hand with Query as well?
> And that's where improved Join support, sorting, pagination, etc. will go?
>
> Alan
>
> On May 30, 2006, at 9:24 AM, Hans Lellelid wrote:
>
>> Hi Alan,
>>
>> I added some more examples to the wiki page.
>>
>> -H
>>
>> Alan Pinstein wrote:
>>> Thanks for kicking this off.
>>>
>>> I posted something about a year ago (I can't believe I've been using
>>> Propel for a year!) and I think most of the comments are still relevant:
>>>
>>> http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609
>>>
>>> You've got a good start, but as you've mentioned, Criteria is currently
>>> good at simple things but not a complex ones. Yet your examples on the
>>> planning page are still relatively simply queries.
>>>
>>> I think we should think about the interface for the more complicated
>>> parts as well:
>>>
>>> 1) Joining and table aliasing
>>> 2) Sorting and pagination
>>>
>>> Can you explain the Query* classes more?
>>>
>>> I'd be happy to contribute time to flushing out design over the next few
>>> weeks.
>>>
>>> Thanks!
>>>
>>> Alan
>>>
>>> On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:
>>>
>>>> Hi -
>>>>
>>>> I put together a rough proposal/strategy for a new Criteria API on the
>>>> wiki page.
>>>>
>>>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>>>>
>>>> The implementation is still only very loosely conceptual and it doesn't
>>>> address all the functionality of the current system yet. It does,
>>>> however, provide a more consistent & somewhat more intuitive system
>>>> (both to use & to develop, in my opinion). The design is based loosely
>>>> on the Hibernate Criteria API and the way that the logical expressions
>>>> are handled by Phing's Condition system.
>>>>
>>>> I think it's a good starting point, and would be interested in any
>>>> comments at this point.
>>>>
>>>> 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
>>>
>>
>> --------------------​--------------------​--------------------​---------
>> 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] Criteria proposal

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-05-30 07:16:34 PDT
Message Nice... looking good.

So I suppose that Criteria2 needs to go hand-in-hand with Query as
well? And that's where improved Join support, sorting, pagination,
etc. will go?

Alan

On May 30, 2006, at 9:24 AM, Hans Lellelid wrote:

> Hi Alan,
>
> I added some more examples to the wiki page.
>
> -H
>
> Alan Pinstein wrote:
>> Thanks for kicking this off.
>>
>> I posted something about a year ago (I can't believe I've been using
>> Propel for a year!) and I think most of the comments are still
>> relevant:
>>
>> http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609
>>
>> You've got a good start, but as you've mentioned, Criteria is
>> currently
>> good at simple things but not a complex ones. Yet your examples on
>> the
>> planning page are still relatively simply queries.
>>
>> I think we should think about the interface for the more complicated
>> parts as well:
>>
>> 1) Joining and table aliasing
>> 2) Sorting and pagination
>>
>> Can you explain the Query* classes more?
>>
>> I'd be happy to contribute time to flushing out design over the
>> next few
>> weeks.
>>
>> Thanks!
>>
>> Alan
>>
>> On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:
>>
>>> Hi -
>>>
>>> I put together a rough proposal/strategy for a new Criteria API
>>> on the
>>> wiki page.
>>>
>>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>>>
>>> The implementation is still only very loosely conceptual and it
>>> doesn't
>>> address all the functionality of the current system yet. It does,
>>> however, provide a more consistent & somewhat more intuitive system
>>> (both to use & to develop, in my opinion). The design is based
>>> loosely
>>> on the Hibernate Criteria API and the way that the logical
>>> expressions
>>> are handled by Phing's Condition system.
>>>
>>> I think it's a good starting point, and would be interested in any
>>> comments at this point.
>>>
>>> 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
>>
>
> --------------------​--------------------​--------------------​---------
> 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] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-30 06:24:56 PDT
Message Hi Alan,

I added some more examples to the wiki page.

-H

Alan Pinstein wrote:
> Thanks for kicking this off.
>
> I posted something about a year ago (I can't believe I've been using
> Propel for a year!) and I think most of the comments are still relevant:
>
> http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609
>
> You've got a good start, but as you've mentioned, Criteria is currently
> good at simple things but not a complex ones. Yet your examples on the
> planning page are still relatively simply queries.
>
> I think we should think about the interface for the more complicated
> parts as well:
>
> 1) Joining and table aliasing
> 2) Sorting and pagination
>
> Can you explain the Query* classes more?
>
> I'd be happy to contribute time to flushing out design over the next few
> weeks.
>
> Thanks!
>
> Alan
>
> On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:
>
>> Hi -
>>
>> I put together a rough proposal/strategy for a new Criteria API on the
>> wiki page.
>>
>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>>
>> The implementation is still only very loosely conceptual and it doesn't
>> address all the functionality of the current system yet. It does,
>> however, provide a more consistent & somewhat more intuitive system
>> (both to use & to develop, in my opinion). The design is based loosely
>> on the Hibernate Criteria API and the way that the logical expressions
>> are handled by Phing's Condition system.
>>
>> I think it's a good starting point, and would be interested in any
>> comments at this point.
>>
>> 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
>

Re: [propel-dev] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-29 11:51:30 PDT
Message Hi Alan,

Sure, I'll put together some more complex examples. In particular, the
logical complex stuff that was so painful before (getNewCriterion(....))
should now be very simple; I'll put together some before & after
examples (Criteria vs. Criteria2).

Also, the new model should make custom SQL straightforward, so I'll put
together some examples of that.

The new Criteria/Query system is still built around Propel, though, so
there's no support for things like custom select columns that are
functions. We could add this, but I'm not sure if it has any
application in Propel & I don't want to complicate the code for
scenarios that will never happen. That said, I think we should make the
package extensible so that people could build off of it for their own
query-building applications.

The basic distinction between Criteria and my Query class (open for
renaming suggestions) is that Criteria handles stuff that goes in a
WHERE-clause. That way, Criteria can be used for UPDATE and DELETE
statements in addition to SELECT queries. The Query class handles
things like adding select columns, specifying order-by, limit, offset,
group by, having, etc. The Query class is instantiated with a Criteria
object, so there is a sense that every query has some Criteria
associated with it -- and, of course, that Criteria object could have
nested Criteria, etc.

Hope that helps make Query a bit clearer. (Check out the more recent
email & ticket for more up-to-date examples than the wiki page.)

Hans

Alan Pinstein wrote:
> Thanks for kicking this off.
>
> I posted something about a year ago (I can't believe I've been using
> Propel for a year!) and I think most of the comments are still relevant:
>
> http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609
>
> You've got a good start, but as you've mentioned, Criteria is currently
> good at simple things but not a complex ones. Yet your examples on the
> planning page are still relatively simply queries.
>
> I think we should think about the interface for the more complicated
> parts as well:
>
> 1) Joining and table aliasing
> 2) Sorting and pagination
>
> Can you explain the Query* classes more?
>
> I'd be happy to contribute time to flushing out design over the next few
> weeks.
>
> Thanks!
>
> Alan
>
> On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:
>
>> Hi -
>>
>> I put together a rough proposal/strategy for a new Criteria API on the
>> wiki page.
>>
>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>>
>> The implementation is still only very loosely conceptual and it doesn't
>> address all the functionality of the current system yet. It does,
>> however, provide a more consistent & somewhat more intuitive system
>> (both to use & to develop, in my opinion). The design is based loosely
>> on the Hibernate Criteria API and the way that the logical expressions
>> are handled by Phing's Condition system.
>>
>> I think it's a good starting point, and would be interested in any
>> comments at this point.
>>
>> 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
>

Re: [propel-dev] Criteria proposal

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-05-29 09:03:50 PDT
Message Thanks for kicking this off.

I posted something about a year ago (I can't believe I've been using
Propel for a year!) and I think most of the comments are still relevant:

http://propel.tigris​.org/servlets/ReadMs​g?list=dev&msgNo​=609

You've got a good start, but as you've mentioned, Criteria is
currently good at simple things but not a complex ones. Yet your
examples on the planning page are still relatively simply queries.

I think we should think about the interface for the more complicated
parts as well:

1) Joining and table aliasing
2) Sorting and pagination

Can you explain the Query* classes more?

I'd be happy to contribute time to flushing out design over the next
few weeks.

Thanks!

Alan

On May 26, 2006, at 2:37 PM, Hans Lellelid wrote:

> Hi -
>
> I put together a rough proposal/strategy for a new Criteria API on the
> wiki page.
>
> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>
> The implementation is still only very loosely conceptual and it
> doesn't
> address all the functionality of the current system yet. It does,
> however, provide a more consistent & somewhat more intuitive system
> (both to use & to develop, in my opinion). The design is based
> loosely
> on the Hibernate Criteria API and the way that the logical expressions
> are handled by Phing's Condition system.
>
> I think it's a good starting point, and would be interested in any
> comments at this point.
>
> 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] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-27 14:21:23 PDT
Message Yes, we simplify the API from the user's perspective (using factory),
but I don't see a clean way to greatly reduce the number of classes
involved. And I don't think that in itself is a bad thing (using many
classes with shared functionality in parent classes seems fairly elegant
in the way it promotes code reuse).

I started thinking of Hibernate's Expression::or() and Expression::and()
... and then realized that 'and' and 'or' cannot be method names in PHP :(

Anyway, we can work with the API. I'll check in a more functional copy
of Criteria2 soon (probably not today, though); that might provide a
better starting point for discussion. In the meantime, there is a
Criteria2.php attached to the wiki page that has some of the
implementation -- albeit in one large file. (Actually, for performance
reasons we may want to keep most of the individual expression classes in
one file.)

I"m building out a Query class right now and reworking the
BasePeer::createSelectSql() method; overall, I'm quite pleased with how
much simpler this new Criteria is, although it's certainly not
functionally complete yet.

Hans

Ants Aasma wrote:
> On the whole the proposal seems pretty good. I hope that I'll have a
> bit more time to think about the design next week and come up with
> more comments. But for now I'd just suggest constructing the
> expression classes with factory methods. This way we could do with
> only a couple of expression classes, cutting down the complexity.
>
> Ants Aasma
>
> On 5/26/06, Hans Lellelid <hans at velum dot net> wrote:
>> Hi -
>>
>> I put together a rough proposal/strategy for a new Criteria API on the
>> wiki page.
>>
>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>>
>> The implementation is still only very loosely conceptual and it doesn't
>> address all the functionality of the current system yet. It does,
>> however, provide a more consistent & somewhat more intuitive system
>> (both to use & to develop, in my opinion). The design is based loosely
>> on the Hibernate Criteria API and the way that the logical expressions
>> are handled by Phing's Condition system.
>>
>> I think it's a good starting point, and would be interested in any
>> comments at this point.
>>
>> 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
>

Re: [propel-dev] Criteria proposal

Reply

Author Ants Aasma <ants dot aasma at gmail dot com>
Full name Ants Aasma <ants dot aasma at gmail dot com>
Date 2006-05-27 12:47:55 PDT
Message On the whole the proposal seems pretty good. I hope that I'll have a
bit more time to think about the design next week and come up with
more comments. But for now I'd just suggest constructing the
expression classes with factory methods. This way we could do with
only a couple of expression classes, cutting down the complexity.

Ants Aasma

On 5/26/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi -
>
> I put together a rough proposal/strategy for a new Criteria API on the
> wiki page.
>
> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>
> The implementation is still only very loosely conceptual and it doesn't
> address all the functionality of the current system yet. It does,
> however, provide a more consistent & somewhat more intuitive system
> (both to use & to develop, in my opinion). The design is based loosely
> on the Hibernate Criteria API and the way that the logical expressions
> are handled by Phing's Condition system.
>
> I think it's a good starting point, and would be interested in any
> comments at this point.
>
> 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] Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-27 09:43:15 PDT
Message David Zülke wrote:
> Am 27.05.2006 um 14:02 schrieb Cameron Brunner:
>
>> +1 for php6 'optimal' output module
>> +1 for php5.1 minimum to run it
>>
>> personally id love to see it all php6 native however i will be quite
>> content with a nice php6 output module
>
> Me too. But it's too early in the game to decide if we could make it
> PHP6 only. If PHP6 is out by the time we're getting close to a
> release, I'd be all for a PHP6-only version, namespaces would be only
> one of the arguments for doing this.
If I can continue to devote time to Propel 2.0 over next few weeks, then
I fully hope that Propel 2.0 will be released before PHP6 -- although I
admit that I have no idea what that timeline is.

I'm hoping to commit a demo Criteria2 tomorrow. It needs a bunch of
work still, though, so not entirely sure if I'll have time to finish it
by then.

The identifier quoting will be implemented as soon as new Criteria
system is in place. Also, self-joins will become possible.

I want to get a benchmark idea, but it will be tricky to benchmark them
side-by-side since I think the Peer constants will need to change from
table.COL_NAME to just COL_NAME (or maybe "col_name" -- getting rid of
that ugly uppercase convention that seems to exist for only Oracle --
and not even sure how necessary that is). The reason for this constant
change would be to facilitate aliasing the tables and remove all the
string parsing that's done in the BasePeer and Criteria classes.

Hans

P.S. I'm gonna tag Propel 1.2.0RC2 in a few minutes -- and hopefully
get that release put up later today or tomorrow too. I think RC2 is
necessary as we've made a bunch of fixes since RC1.

Re: [propel-dev] Criteria proposal

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 2006-05-27 08:17:09 PDT
Message Am 27.05.2006 um 14:02 schrieb Cameron Brunner:

> +1 for php6 'optimal' output module
> +1 for php5.1 minimum to run it
>
> personally id love to see it all php6 native however i will be quite
> content with a nice php6 output module

Me too. But it's too early in the game to decide if we could make it
PHP6 only. If PHP6 is out by the time we're getting close to a
release, I'd be all for a PHP6-only version, namespaces would be only
one of the arguments for doing this.

Re: [propel-dev] Criteria proposal

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-05-27 05:02:31 PDT
Message +1 for php6 'optimal' output module
+1 for php5.1 minimum to run it

personally id love to see it all php6 native however i will be quite
content with a nice php6 output module


Cameron

On 5/27/06, David Zülke <dz at bitxtender dot com> wrote:
> > combine the above with spl_autoload?
>
> Yes. I think we should aim for PHP 5.1 or even 5.2 as the target
> version. Depending on how far along PHP6 is when we have something
> working, we might at least want to have optional PHP6 (read:
> namespaces and maybe unicode) support.
>
> - David

Re: [propel-dev] Criteria proposal

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 2006-05-27 04:30:33 PDT
Message > combine the above with spl_autoload?

Yes. I think we should aim for PHP 5.1 or even 5.2 as the target
version. Depending on how far along PHP6 is when we have something
working, we might at least want to have optional PHP6 (read:
namespaces and maybe unicode) support.

- David

Re: [propel-dev] Criteria proposal

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-05-26 22:12:34 PDT
Message +1 for the idea of multiple mini classes, this is more or less what i
had in mind when i was looking at it at first when we were talking
about 2.0

combine the above with spl_autoload?


Cameron

On 5/27/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi -
>
> I put together a rough proposal/strategy for a new Criteria API on the
> wiki page.
>
> http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria
>
> The implementation is still only very loosely conceptual and it doesn't
> address all the functionality of the current system yet. It does,
> however, provide a more consistent & somewhat more intuitive system
> (both to use & to develop, in my opinion). The design is based loosely
> on the Hibernate Criteria API and the way that the logical expressions
> are handled by Phing's Condition system.
>
> I think it's a good starting point, and would be interested in any
> comments at this point.
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Criteria proposal

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-05-26 11:37:28 PDT
Message Hi -

I put together a rough proposal/strategy for a new Criteria API on the
wiki page.

http://propel.phpdb.​org/trac/wiki/Develo​pment/Criteria

The implementation is still only very loosely conceptual and it doesn't
address all the functionality of the current system yet. It does,
however, provide a more consistent & somewhat more intuitive system
(both to use & to develop, in my opinion). The design is based loosely
on the Hibernate Criteria API and the way that the logical expressions
are handled by Phing's Condition system.

I think it's a good starting point, and would be interested in any
comments at this point.

Hans
Messages per page: