headers
Eric Fredj | 1 Dec 2007 01:03
Picon

Re: Re: [propel-cvs] SVN update: r838 - branches/1.3/generator/classes/propel/engine/builder/om/php5

Hans Lellelid a écrit :
> I think so ...  the new Criteria::CUSTOM support is really very
> different from the current behavior of Criteria::CUSTOM.  I think at a
> minimum it would be really confusing to have it behave one way in one
> context and another in a different context.
>
> Let's just choose a new operator.  Maybe CUSTOM_EQUATION, CUSTOM_EQUAL,
> CUSTOM_EQ ... ?
I understand your point.
Mine about not reverting was not to keep CUSTOM word but to keep
implementation.

CUSTOM_EQUAL sounds good to me.

Heltem
Permalink | Reply | 1 comment |
headers
Hans Lellelid | 1 Dec 2007 02:52

Re: Re: [propel-cvs] SVN update: r838 - branches/1.3/generator/classes/propel/engine/builder/om/php5

Eric Fredj wrote:
> Hans Lellelid a écrit :
>> I think so ...  the new Criteria::CUSTOM support is really very
>> different from the current behavior of Criteria::CUSTOM.  I think at a
>> minimum it would be really confusing to have it behave one way in one
>> context and another in a different context.
>>
>> Let's just choose a new operator.  Maybe CUSTOM_EQUATION, CUSTOM_EQUAL,
>> CUSTOM_EQ ... ?
> I understand your point.
> Mine about not reverting was not to keep CUSTOM word but to keep
> implementation.
> 
> CUSTOM_EQUAL sounds good to me.

Ok -- I understand & I agree that it makes more sense to just update the
keyword rather than revert the change.  (Which is partly why I didn't
revert anything! -- Plus, I figured we should reach a decision before
any action was taken :)

Hans
Permalink | Reply | 0 comments |
headers
Hans Lellelid | 1 Dec 2007 14:46

Re: [propel-cvs] SVN update: r839 - in branches/1.3: generator/classes/propel/engine/builder/om/php5 runtime/classes/propel/util

Thanks, Eric!

Hans

propel <at> svn.phpdb.org wrote:
> Author: heltem
> Date: 2007-12-01 10:11:40 +0000 (Sat, 01 Dec 2007)
> New Revision: 839
> 
> Modified:
>    branches/1.3/generator/classes/propel/engine/builder/om/php5/PHP5NestedSetPeerBuilder.php
>    branches/1.3/runtime/classes/propel/util/BasePeer.php
>    branches/1.3/runtime/classes/propel/util/Criteria.php
> Log:
> Add Criteria::CUSTOM_EQUAL
> Replace Criteria::CUSTOM usage in BasePeer::doUpdate() by Criteria::CUSTOM_EQUAL
> 
> Modified: branches/1.3/generator/classes/propel/engine/builder/om/php5/PHP5NestedSetPeerBuilder.php
> ===================================================================
> ---
branches/1.3/generator/classes/propel/engine/builder/om/php5/PHP5NestedSetPeerBuilder.php	2007-11-30
16:49:10 UTC (rev 838)
> +++
branches/1.3/generator/classes/propel/engine/builder/om/php5/PHP5NestedSetPeerBuilder.php	2007-12-01
10:11:40 UTC (rev 839)
>  <at>  <at>  -1467,7 +1467,7  <at>  <at> 
>  
>  		\$valuesCriteria = new Criteria();
>  		\$param = array('raw' => \$leftUpdateCol . \" + ?\", 'value' => \$delta);
> -		\$criterion = \$valuesCriteria->getNewCriterion(self::LEFT_COL, \$param, Criteria::CUSTOM);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Fredj | 1 Dec 2007 15:16
Picon

Re: Re: [propel-cvs] SVN update: r839 - in branches/1.3: generator/classes/propel/engine/builder/om/php5 runtime/classes/propel/util

Hans Lellelid a écrit :
> Thanks, Eric!
>
> Hans
>   
You're welcome.

Heltem
Permalink | Reply | 0 comments |
headers
Christian Abegg | 2 Dec 2007 15:26
Picon

Re: r/w splitting in master-slave db replication environment


hi there

here's a refinend implementation of r/w splitting: 
http://www.nabble.com/file/p14116000/rwSplitting.zip rwSplitting.zip 

anyone interested?

regards
christian

Christian Abegg wrote:
> 
> hi cameron, dear devs
> 
> thank you for your reply. i made a first try to implement it the way you
> proposed:
> - the propel class initializes a PropelPDO object which acts as db
> connection to the master server
> - the PropelPDO object also holds an array of other PDO connections used
> for read only queries
> 
> pro: realtively simple to implement, building up on the existing code
> contra: PropelPDO extending PDO is no more used as a singe db connection
> 
> have a look at the two patches attached. they are a very first draft
> showing the way I would choose. 
>  http://www.nabble.com/file/p13820966/Propel.diff Propel.diff 
>  http://www.nabble.com/file/p13820966/PropelPDO.diff PropelPDO.diff 
>
(Continue reading)

Permalink | Reply | 21 comments |
headers
Hans Lellelid | 2 Dec 2007 18:15

nested-set tree documentation & tests

Hi Heltem & others -

I want to do what I can to help get the nested set stuff packaged up for
release later this month.  I know that there are a few open tickets, but
assume we're probably pretty close.  One thing that would be *huge*
would be to get a set of unit tests in place for this.  Someone on list
was mentioning that we could base our tests on the Symfony nested set
behavior tests.  That should be completely fine too -- provided we give
appropriate attribution / copyright on those :)

I created a new 'book_category' table within the bookstore schema.xml to
use for unit testing.  I also created a currently empty unit test class
that can serve as a container for adding the tests
GeneratedNestedSetTest.php

It seems there are a couple versions of the documentation online:
1) http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/Tree/NestedSet
2)
http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/Tree/NestedSet/StillInDev

A few notes as I tried to follow instructions:
 - I notice that for part of the instructions in (2) there is a call
insertAsSiblingOf($root) -- which results in an error "Root nodes cannot
have siblings"  For a root node to have siblings must I use the
treeScopeId to establish multiple trees?
 - I added the parent attribute as in the example schema.xml, but I got
this error: "Element 'column', attribute 'treeParentKey': The attribute
'treeParentKey' is not allowed."  I assume we are no longer using that
attribute?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Lellelid | 2 Dec 2007 19:09

SERIAL support for Postgres in 1.3

Thanks to Kevin's urging and provided patch (yes, long ago, I know), I
have re-examined the SERIAL issue w/ Postgres and I'm not sure there's
any reason not to use SERIAL for the auto-increment columns instead of
the sequence approach.

I applied a modified version of Kevin's patch.  Our existing unit tests
pass fine, though that's not really surprising.  Hopefully I will be
able to test this out with some already-developed applications, but I'm
eager to know whether other people can help test this with any existing
applications running on Postgres.

For those that want to continue using the SEQUENCE mode for
auto-increment columns, you can extend the PgsqlPlatform class and
override the getNativeIdMethod() method:

class MyPgsqlPlatform {
 public function getNativeIdMethod()
 {
  return Platform::SERIAL;
 }
}

See
http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/BuildProperties#OverridingBuilderClasses
for how to tell Propel to use your Platform class.

Let me know if you discover any problems or have questions about this
implementation.

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Lellelid | 3 Dec 2007 02:02

Propel 1.3.0beta3

Hi folks,

In order to make it easier for people who prefer not to use SVN to help
us test out the 1.3 version of Propel, I've uploaded a 1.3.0beta3
release to the channel server.  You should be able to upgrade (or
install) using PEAR installer:

pear upgrade phpdb/propel_generator
pear upgrade phpdb/propel_runtime

Please note that you will want to rebuild your OM to take advantage of
any of the generator bugfixes since beta2.

Also note that lots of stuff has changed / been improved.  Please see
http://propel.phpdb.org/trac/query?status=closed&milestone=1.3&resolution=fixed&order=priority
for a list of all the issues that have been fixed for 1.3 (and you can
add additional filters there -- e.g. to narrow down issues fixed that
were reported for 1.3.0beta2).

A lot of the recent work has been around date/time value handling and
default values.  One rather big change that was just committed was to
switch Postgres to use SERIAL for auto-increment columns.  Since
Postgres is really still using sequences behind the scenes, this
shouldn't change the API behavior, but this is worth bearing in mind.

Note that there is ongoing work with the nested-set tree
implementation.  You can expect an RC release once the tree stuff is
more finalized and we have made a decision about some of the outstanding
enhancements.  I'm hoping that we can release the first stable 1.3.0
release by the end of the month.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hans Lellelid | 3 Dec 2007 02:05

Re: Propel 1.3.0beta3

Also see http://propel.phpdb.org/trac/wiki/Users/News/Propel1.3.0beta3
for a few more release notes.

Hans

Hans Lellelid wrote:
> Hi folks,
> 
> In order to make it easier for people who prefer not to use SVN to help
> us test out the 1.3 version of Propel, I've uploaded a 1.3.0beta3
> release to the channel server.  You should be able to upgrade (or
> install) using PEAR installer:
> 
> pear upgrade phpdb/propel_generator
> pear upgrade phpdb/propel_runtime
> 
> Please note that you will want to rebuild your OM to take advantage of
> any of the generator bugfixes since beta2.
> 
> Also note that lots of stuff has changed / been improved.  Please see
> http://propel.phpdb.org/trac/query?status=closed&milestone=1.3&resolution=fixed&order=priority
> for a list of all the issues that have been fixed for 1.3 (and you can
> add additional filters there -- e.g. to narrow down issues fixed that
> were reported for 1.3.0beta2).
> 
> A lot of the recent work has been around date/time value handling and
> default values.  One rather big change that was just committed was to
> switch Postgres to use SERIAL for auto-increment columns.  Since
> Postgres is really still using sequences behind the scenes, this
> shouldn't change the API behavior, but this is worth bearing in mind.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Lellelid | 3 Dec 2007 02:22

Re: r/w splitting in master-slave db replication environment

Hi Christian,

Yes :)

Am I right in assuming that this will work fine without a master/slave
setup? (i.e. in traditional, single-db model?)

I didn't drop these in to do a diff, but the PropelPDO looked fairly
similar; Propel class too?

I'd like to get this added in, though.  I think it would be a great benefit.

Would you be willing to contribute some documentation on getting this
setup?  -- e.g. in 1.3 user guide?

Thanks,
Hans

Christian Abegg wrote:
> hi there
> 
> here's a refinend implementation of r/w splitting: 
> http://www.nabble.com/file/p14116000/rwSplitting.zip rwSplitting.zip 
> 
> anyone interested?
> 
> regards
> christian
> 
>
(Continue reading)

Permalink | Reply | 20 comments |

Gmane