I will try to explain how work the caching system in my application.
I have this table : tree_line_id, parent_id, tree_id, other fields ...
- each line of a same tree share the same tree_id
- I load the tree data with 1 query SELECT * FROM table where
tree_id = 1
- I have added to my propel object TreeLine::addChild,
TreeLine::setParent and TreeLine::removeChild methods
- I have added to my propel peer object TreeLinePeer::_loadTree,
TreeLinePeer::loadTree, TreeLinePeer::saveTree,
TreeLinePeer::addChild, TreeLinePeer::deleteChild
- In the loop to assign child and parent, I also create an hash
array with reference to my propel object, so I can get a node with
$array[$id]
- This code is used with propel 1.2
For the following code I have this relation : Estimate > EstimateLine
(nested set). The root node id is always -1
The load function look like this, the nested set is on the
EstimateLine object:
private static function &_loadTree(Estimate $estimate) {
$c = new Criteria;
$c->add(EstimateLinePeer::ESTIMATE_ID, $estimate->getEstimateId(),
Criteria::EQUAL);
$lines = EstimateLinePeer::doSelect($c);
$aLines = array();
foreach($lines as &$line) {
$pId = $line->getParentId();
$id = $line->getEstimateLineId();
if(!$aLines[$pId]) {
$aLines[$pId] = new EstimateLine;
$aLines[$pId]->setEstimateId($estimate->getEstimateId());
$aLines[$pId]->setEstimateLineId($pId);
$aLines[$pId]->setNew(false);
}
if(!($aLines[$id] instanceof EstimateLine)) {
$aLines[$id] =& $line;
} else {
$line->copyInto($aLines[$id]);
$aLines[$id]->setNew(false);
$aLines[$id]->setEstimateLineId($id);
}
$aLines[$pId]->addChild($aLines[$id]);
$aLines[$id]->setParent($aLines[$pId]);
}
if(count($aLines) == 0) {
// create the default one
$aLines[-1] = new EstimateLine;
$aLines[-1]->setEstimateId($estimate->getEstimateId());
$aLines[-1]->setEstimateLineId(-1);
}
if(!($aLines[-1] instanceof EstimateLine)) {
throw new OreoException('Consistancy error, no root node for thre
current estimate (id='.$estimate->getEstimateId().')');
}
$aLines[-1]->setDescription(__('Estimate').' '.$estimate-
>getReference());
return $aLines;
}
The tree is stored in a static variable in the Peer class. In order
to get the nodes you just provide the tree_id the method loadTree
check if a cache version exist or not and return the reference to the
array
public static function &loadTree(Estimate $estimate) {
@mkdir(MORO_DATA_MODULES_PATH.'/estimates/cache/', 0777, true);
$file_name = MORO_DATA_MODULES_PATH.'/estimates/cache/'.$estimate-
>getEstimateId().'_estimate_lines.cache';
if(self::$tree[$estimate->getEstimateId()]) {
return self::$tree[$estimate->getEstimateId()];
} else if(is_file($file_name)) {
Syslog::debug('Reload from serialization, estimate_id='.$estimate-
>getEstimateId());
self::$tree[$estimate->getEstimateId()] = unserialize
(file_get_contents($file_name));
} else {
Syslog::debug('Serialize + cache, estimate_id='.$estimate-
>getEstimateId());
self::$tree[$estimate->getEstimateId()] =& EstimatePeer::_loadTree
($estimate);
self::saveTree($estimate);
}
return self::$tree[$estimate->getEstimateId()];
}
When you make any change to one object you have to save the tree
public function saveTree(Estimate &$estimate) {
@mkdir(MORO_DATA_MODULES_PATH.'/estimates/cache/', 0777, true);
$file_name = MORO_DATA_MODULES_PATH.'/estimates/cache/'.$estimate-
>getEstimateId().'_estimate_lines.cache';
Syslog::debug('Saving Cache, estimate_id='.$estimate->getEstimateId
());
file_put_contents($file_name,serialize(self::$tree[$estimate-
>getEstimateId()]));
}
When you delete an object or add a child you have to update the
database and the cache
public function addChild($estimate, &$child) {
if($estimate instanceof Estimate) {
$id = $estimate->getEstimateId();
} else {
$id = $estimate;
}
self::$tree[$id][$child->getEstimateLineId()] =& $child;
}
public function deleteChild($estimateLine) {
$parent =& $estimateLine->getParent();
$idx = array_merge($estimateLine->getIdxChild(), array
($estimateLine->getEstimateLineId()));
$estimate = EstimatePeer::retrieveByPK($estimateLine->getEstimateId
());
if(!($estimate instanceof Estimate)) {
throw new OreoException('Unable get the estimate', OREO_ERROR_CHECK);
}
$c = new Criteria;
$c->add(EstimateLinePeer::ESTIMATE_LINE_ID, $idx, Criteria::IN);
EstimateLinePeer::doDelete($c);
// Update the cache tree
foreach($idx as $idChild) {
syslog::debug('Delete node from cache tree : estimate_id='.
$estimate->getEstimateId().' , estimate_line_id='.$idChild);
// remove parent reference
$parent = self::$tree[$estimate->getEstimateId()][$idChild]-
>getParent();
if($parent instanceof EstimateLine) {
$parent->removeChild(self::$tree[$estimate->getEstimateId()]
[$idChild]);
}
unset(self::$tree[$estimate->getEstimateId()][$idChild]);
}
EstimatePeer::saveTree($estimate);
}
you can reimplement the retrievebypk method :
public static function &retrieveByPk($pk) {
$line = parent::retrieveByPk($pk);
$estimate = EstimatePeer::retrieveByPk($line->getEstimateId());
$lines =& EstimatePeer::loadTree($estimate);
return $lines[$pk];
}
Of course you have to implement save and delete method in your
object. So when you use this cache system it is transparency in your
action :
$estimate = new Estimate;
$estimate->save();
$estimate2 = new Estimate;
$estimate2->save();
$estimate->addChild($estimate2);
$estimate->save();
$estimate2->delete();
Other important points :
- this optimization improves processing speed if you have to load
1000 objects. Up to 10x faster and it is very easy to access to any
point of the nested set. However it is very easy to get lost with
references. And you have to make sure you always use the reference
object and not a copy.
- If you have a complex nested set relation, ie : margin
calculation over nested set with up and down propagation. I suppose
that your database contains always correct values, the propagation/
cascade update is not required when loading from database. You may
find usefull in the loading method to set a state variable to not
cascade information over child or/and parent.
function setMargin($val) {
parent::setMargin($val);
if(self::$propagation) {
$this->getParent()->updateMargin();
}
}
- the caching solution rely on the filesystem as the serialization
is store in a file. Depends on the load and disk access this method
can be worth that reloading from database. If you have APC installed
on your server you can also use the share memory to store the cache
array.
I hope these few lines can help you to create a caching solution for
your nested set.
Thomas.
On 27 déc. 06, at 23:46, Eric Fredj wrote:
> Thomas,
>
> Have you some hints to share with us to implement some caching
> system for Nested Set ?
> I am interested in implement a common caching system for trees
> implementations (Nested Set or Materialized Path).
>
> ErIC
>

Eric Fredj wrote:> <snip>> > Hans, sorry for the way I provide patch, it is a svn diff between > current branch and my modified one ;-)> In fact, the patch brings some new file (Builder, Iterator) and require > some modification on the core to integrate new builder calls, schema > reworking to read some added attributes.> How do you advise me to commit my patch ? I can commit in several times: > new files (1), builder integration (2), schema addition (3), and then > existing phing task update (4).> Would it be ok for you ?

There's no problem with providing a patch like that; it's what I was expecting. As for how you commit it, you can commit in one commit, that's fine. What I was saying earlier was just that it would be good to indicate in the source code (e.g. if you are modifying methods that already existed in the base classes before) which code is specific to the nestedset. Looking more at your design, though, it looks like it will be fairly clear.

So, you can still use Menu object, the only difference is that you have moremethods available.To get a full Tree support, it remains to integrate Node (MaterializedPathtype) object and peer in the same way with an common interface shared withNestedSet.

Menu and MenuPeer are still used with same methods whatever Node and Treesare handled.

Hans, sorry for the way I provide patch, it is a svn diff between currentbranch and my modified one ;-)In fact, the patch brings some new file (Builder, Iterator) and require somemodification on the core to integrate new builder calls, schema reworking toread some added attributes.How do you advise me to commit my patch ? I can commit in several times: newfiles (1), builder integration (2), schema addition (3), and then existingphing task update (4).Would it be ok for you ?

And I really have to take some time to make documentation, you're right.I hope, after new year, I will have a really stable Internet access to makeit possible.

Thomas, I didn't work on a NestedSet specific caching system , because, Irely on BaseModelPeer class so, I consider its responsability to providecaching ... :-)However, I agree with you caching is a need for performance...

Merry Xmas and Happy New Year.

On 12/24/06, Hans Lellelid <hans at velum dot net> wrote:>> Hi Eric,>> Also, if you could expand any documentation on the wiki, that would be> very helpful! :)>> Hans>> Hans Lellelid wrote:> > Hi Eric,> >> > This all looks really great. My only suggestion is that as you create> > this patch, if you could try to keep it clear which additions to the> > main peer/object are nested set-related. That way, when we introduce> > something like "features" support, turning all these peer customization> > options into encapsulated add-ons, it will be easy to identify those> > components.> >> > Thanks for your contribution!> >> > 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>>

Also, if you could expand any documentation on the wiki, that would be very helpful! :)

Hans

Hans Lellelid wrote:> Hi Eric,> > This all looks really great. My only suggestion is that as you create > this patch, if you could try to keep it clear which additions to the > main peer/object are nested set-related. That way, when we introduce > something like "features" support, turning all these peer customization > options into encapsulated add-ons, it will be easy to identify those > components.> > Thanks for your contribution!> > Hans> > Eric Fredj wrote:>> Fix typo>>>> Example Ttaversal usage>> $root = MenuNestedSetPeer::r​etrieveRoot();>> $level = 0;>> foreach($root as $node) {>> if($level < $node->getLevel()) {>> // Go deep (to leaf) in tree>> } else if ($level > $node->getLevel()) {>> // Go up (to root) in tree>> } else {>> // Stay in same level>> }>> $level = $node->getLevel();>> }>>>> On 12/24/06, *Eric Fredj* <eofredj at gmail dot com >> <mailto:eofredj@g​mail.com>> wrote:>>>> Ok, as promised, I made a patch on 1.3 branch in order to add>> NestedSet support.>>>> I didn't commit it because, I am not currently satisfied.>> Indeed, it is fully usable but it requires to use a specific Stub>> and StubPeer in parallel with default ones.>>>> So I decided to work now on an really integrated way to use>> NestedSet in a transparent way...>>>> Now provided features:>>>> * New builder to generate NestedSet object, peer and their stubs>> * Support for Iterator on NestedSet node in order to use it in>> a PreOrderTraversal way>> * Support for IteratorAggregate to retrieve right Iterator to use>> * Extended PropelPDO to add logging in prepare() method>>>> Example insertion usage>>>> $menu = new MenuNestedSet();>> $menu->setText('Google');>> $menu->setLink('http://www.google.com'>> <http://www.google.com%27>);>>>> MenuNestedSetPeer::c​reateRoot($menu);>>>>>> $child = new MenuNestedSet();>> $child->setText('Google Mail');>> $child->setLink('>> http://mail.google.com' <http://mail.google.com%27>);>> $child->insertAs​LastChildOf($menu);​>>>>>> $child = new MenuNestedSet();>> $child->setText('Google Maps');>> $child->setLink('>> http://maps.google.com' <http://maps.google.com%27>);>> $child->insertAs​LastChildOf($menu);​>>>>>> $sibling = new MenuNestedSet();>> $sibling->setText('Yahoo!');>> $sibling->setLink('>> http://www.yahoo.com' <http://www.yahoo.com%27>);>> $sibling->insert​AsNextSiblingOf($me​nu);>>>>>> $child = new MenuNestedSet();>> $child->setText('Yahoo! Mail');>> $child->setLink('>> http://mail.yahoo.com' <http://mail.yahoo.com%27>);>>>> $child->insertAs​LastChildOf($siblin​g);>>>>>> Example Ttaversal usage>> $node = MenuNestedSetPeer::r​etrieveRoot();>> $level = 0;>> foreach($element as $node) {>> if($level < $node->getLevel()) {>> // Go deep (to leaf) in tree>> } else if ($level > $node->getLevel()) {>> // Go up (to root) in tree>> } else {>> // Stay in same level>> }>> $level = $node->getLevel();>> }>>>> Enjoy it.>>>> Happy X-Mas>> ErIC>>>>>> On 12/18/06, *Eric Fredj* < eofredj at gmail dot com>> <mailto:eofredj@g​mail.com>> wrote:>>>> Ok, I didn't take a look on 1.3 branch until now but I think I>> can adapt the patch quickly.>> I will try to produce before X-Mas.>> By that time, I will attach the 1.2 patch on a Trac ticket>> when phpdb.org <http://phpdb.org> will be up :-)>>>> About coding guidelines, I tried to follow NodePeerBuilder*>> convention and all I was able to read on Trac Wiki but feel>> free to comment and make feedback ...>>>> PS :I asked for SVN account a few minutes ago ..>>>> Thx>> ErIC>>>>>>>> On 12/18/06, *Hans Lellelid* < hans at velum dot net>> <mailto:hans@velu​m.net>> wrote:>>>> Hi Eric,>>>> Makes sense, ok. I think that this makes most sense in>> the 1.3 branch,>> as it would break 1.2 BC (and 1.3 is not far from being>> ready). So, if>> you want to create a ticket (or find that original ticket,>> if there is>> one) and commit this stuff to 1.3, please do (and>> thanks!). Please see>> coding & contributing guidelines, of course. Also let me>> know if you>> need SVN account.>>>> Thanks,>> Hans>>>>>> Eric Fredj wrote:>> > I forgot the main : I obviously made some specific>> NestedSet builder>> > for Base classes and Stub classes ...>> >>> > On 12/18/06, *Eric Fredj* < eofredj at gmail dot com>> <mailto:eofredj@g​mail.com>>> > <mailto:eofredj at gmail dot com <mailto:eofredj@g​mail.com>>>​>> wrote:>> >>> > Patch was made in mind to be integrated in main tree>> because it>> > requires some changes on the core:>> >>> > * database.xsd was updated to support some new>> attributes in>> > schema.xml>> > o In fact, I replaced isTree by treeMode in>> Table>> > attribute to support several mode>> > o I added some Column attribute to target>> left and right>> > fields>> > * PropelOMTask.php was modified to managed the>> new treeMode>> > and call the new builder I added when needed>> > * Column.php and Table.php to handle their new>> attributes>> > * OMBuilder.php to handle new attributes and>> builder getter as>> > it is done for Node builder>> >>> > Maybe the right way to share would be to create a>> parallel>> > 1.2-nestedset (or something else) branch in which I>> could commit>> > my job, improve it, fix it before you can merge it>> with main 1.2>> > officiel branch.>> > Moreover, it could be more easy to develop the same>> patch for 1.3>> > then...>> >>> >>> >>> > On 12/18/06, *Hans Lellelid* < hans at velum dot net>> <mailto:hans at velum dot net>>> > <mailto: hans at velum dot net <mailto:hans@velu​m.net>>>>> wrote:>> >>> > Hi Eric,>> >>> > Depending on what it is you've been creating, I>> think we can>> > either add>> > it to contrib or integrate it into main tree. My>> preference>> > would be to>> > add it to the contrib directory in SVN. I can>> get you an SVN>> > account if>> > you don't have one yet (please email offlist w/>> desired username).>> >>> >>> >>>>> >> --------------------​--------------------​--------------------​--------->> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org>> <mailto:dev-unsub​scribe at propel dot tigris​.org>>> For additional commands, e-mail:>> dev-help at propel dot tigris dot org >> <mailto:dev-help@​propel.tigris.org​>>>>>>>>>>>> > --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>

Do you have plan to create a caching system for the nested set ? For one project I serialize/desrialize the node root, and I have made a benchmark and I get this results: - loading from database : 0.18s - loading from serialization : 0.014s

The benchmark is made over 1000 rows and propel 1.2

Thomas

On 24 déc. 06, at 11:52, Eric Fredj wrote:

> Ok, as promised, I made a patch on 1.3 branch in order to add > NestedSet support.>> I didn't commit it because, I am not currently satisfied.> Indeed, it is fully usable but it requires to use a specific Stub > and StubPeer in parallel with default ones.>> So I decided to work now on an really integrated way to use > NestedSet in a transparent way...>> Now provided features:> New builder to generate NestedSet object, peer and their stubs> Support for Iterator on NestedSet node in order to use it in a > PreOrderTraversal way> Support for IteratorAggregate to retrieve right Iterator to use> Extended PropelPDO to add logging in prepare() method> Example insertion usage> $menu = new MenuNestedSet();> $menu->setText('Google');> $menu->setLink('http://www.google.com');>> MenuNestedSetPeer::c​reateRoot($menu);>> $child = new MenuNestedSet();> $child->setText('Google Mail');> $child->setLink('http://mail.google.com');> $child->insertAs​LastChildOf($menu);​>> $child = new MenuNestedSet();> $child->setText('Google Maps');> $child->setLink('http://maps.google.com');> $child->insertAs​LastChildOf($menu);​>> $sibling = new MenuNestedSet();> $sibling->setText('Yahoo!');> $sibling->setLink('http://www.yahoo.com');> $sibling->insert​AsNextSiblingOf($me​nu);>> $child = new MenuNestedSet();> $child->setText('Yahoo! Mail');> $child->setLink('http://mail.yahoo.com');>> $child->insertAs​LastChildOf($siblin​g);> Example Ttaversal usage> $node = MenuNestedSetPeer::r​etrieveRoot();> $level = 0;> foreach($element as $node) {> if($level < $node->getLevel()) {> // Go deep (to leaf) in tree> } else if ($level > $node->getLevel()) {> // Go up (to root) in tree> } else {> // Stay in same level> }> $level = $node->getLevel();> }>> Enjoy it.>> Happy X-Mas> ErIC>> On 12/18/06, Eric Fredj <eofredj at gmail dot com> wrote: Ok, I didn't > take a look on 1.3 branch until now but I think I can adapt the > patch quickly.> I will try to produce before X-Mas.> By that time, I will attach the 1.2 patch on a Trac ticket when > phpdb.org will be up :-)>> About coding guidelines, I tried to follow NodePeerBuilder* > convention and all I was able to read on Trac Wiki but feel free to > comment and make feedback ...>> PS :I asked for SVN account a few minutes ago ..>> Thx> ErIC>>>> On 12/18/06, Hans Lellelid < hans at velum dot net> wrote: Hi Eric,>> Makes sense, ok. I think that this makes most sense in the 1.3 > branch,> as it would break 1.2 BC (and 1.3 is not far from being ready). > So, if> you want to create a ticket (or find that original ticket, if there is> one) and commit this stuff to 1.3, please do (and thanks!). Please > see> coding & contributing guidelines, of course. Also let me know if you> need SVN account.>> Thanks,> Hans>>> Eric Fredj wrote:> > I forgot the main : I obviously made some specific NestedSet builder> > for Base classes and Stub classes ...> >> > On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> > <mailto:eofredj@g​mail.com>> wrote:> >> > Patch was made in mind to be integrated in main tree because it> > requires some changes on the core:> >> > * database.xsd was updated to support some new attributes in> > schema.xml> > o In fact, I replaced isTree by treeMode in Table> > attribute to support several mode> > o I added some Column attribute to target left and > right> > fields> > * PropelOMTask.php was modified to managed the new treeMode> > and call the new builder I added when needed> > * Column.php and Table.php to handle their new attributes> > * OMBuilder.php to handle new attributes and builder > getter as> > it is done for Node builder> >> > Maybe the right way to share would be to create a parallel> > 1.2-nestedset (or something else) branch in which I could commit> > my job, improve it, fix it before you can merge it with main 1.2> > officiel branch.> > Moreover, it could be more easy to develop the same patch for > 1.3> > then...> >> >> >> > On 12/18/06, *Hans Lellelid* < hans at velum dot net> > <mailto: hans at velum dot net>> wrote:> >> > Hi Eric,> >> > Depending on what it is you've been creating, I think we can> > either add> > it to contrib or integrate it into main tree. My preference> > would be to> > add it to the contrib directory in SVN. I can get you an > SVN> > account if> > you don't have one yet (please email offlist w/ desired > username).> >> >> >>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>>>> <1.3-nestedset.diff>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org

This all looks really great. My only suggestion is that as you create this patch, if you could try to keep it clear which additions to the main peer/object are nested set-related. That way, when we introduce something like "features" support, turning all these peer customization options into encapsulated add-ons, it will be easy to identify those components.

Thanks for your contribution!

Hans

Eric Fredj wrote:> Fix typo>> Example Ttaversal usage> $root = MenuNestedSetPeer::r​etrieveRoot();> $level = 0;> foreach($root as $node) {> if($level < $node->getLevel()) {> // Go deep (to leaf) in tree> } else if ($level > $node->getLevel()) {> // Go up (to root) in tree> } else {> // Stay in same level> }> $level = $node->getLevel();> }>> On 12/24/06, *Eric Fredj* <eofredj at gmail dot com > <mailto:eofredj@g​mail.com>> wrote:>> Ok, as promised, I made a patch on 1.3 branch in order to add> NestedSet support.>> I didn't commit it because, I am not currently satisfied.> Indeed, it is fully usable but it requires to use a specific Stub> and StubPeer in parallel with default ones.>> So I decided to work now on an really integrated way to use> NestedSet in a transparent way...>> Now provided features:>> * New builder to generate NestedSet object, peer and their stubs> * Support for Iterator on NestedSet node in order to use it in> a PreOrderTraversal way> * Support for IteratorAggregate to retrieve right Iterator to use> * Extended PropelPDO to add logging in prepare() method>> Example insertion usage>> $menu = new MenuNestedSet();> $menu->setText('Google');> $menu->setLink('http://www.google.com'> <http://www.google.com%27>);>> MenuNestedSetPeer::c​reateRoot($menu);>>> $child = new MenuNestedSet();> $child->setText('Google Mail');> $child->setLink('> http://mail.google.com' <http://mail.google.com%27>);> $child->insertAs​LastChildOf($menu);​>>> $child = new MenuNestedSet();> $child->setText('Google Maps');> $child->setLink('> http://maps.google.com' <http://maps.google.com%27>);> $child->insertAs​LastChildOf($menu);​>>> $sibling = new MenuNestedSet();> $sibling->setText('Yahoo!');> $sibling->setLink('> http://www.yahoo.com' <http://www.yahoo.com%27>);> $sibling->insert​AsNextSiblingOf($me​nu);>>> $child = new MenuNestedSet();> $child->setText('Yahoo! Mail');> $child->setLink('> http://mail.yahoo.com' <http://mail.yahoo.com%27>);>> $child->insertAs​LastChildOf($siblin​g);>>> Example Ttaversal usage> $node = MenuNestedSetPeer::r​etrieveRoot();> $level = 0;> foreach($element as $node) {> if($level < $node->getLevel()) {> // Go deep (to leaf) in tree> } else if ($level > $node->getLevel()) {> // Go up (to root) in tree> } else {> // Stay in same level> }> $level = $node->getLevel();> }>> Enjoy it.>> Happy X-Mas> ErIC>>> On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> <mailto:eofredj@g​mail.com>> wrote:>> Ok, I didn't take a look on 1.3 branch until now but I think I> can adapt the patch quickly.> I will try to produce before X-Mas.> By that time, I will attach the 1.2 patch on a Trac ticket> when phpdb.org <http://phpdb.org> will be up :-)>> About coding guidelines, I tried to follow NodePeerBuilder*> convention and all I was able to read on Trac Wiki but feel> free to comment and make feedback ...>> PS :I asked for SVN account a few minutes ago ..>> Thx> ErIC>>>> On 12/18/06, *Hans Lellelid* < hans at velum dot net> <mailto:hans@velu​m.net>> wrote:>> Hi Eric,>> Makes sense, ok. I think that this makes most sense in> the 1.3 branch,> as it would break 1.2 BC (and 1.3 is not far from being> ready). So, if> you want to create a ticket (or find that original ticket,> if there is> one) and commit this stuff to 1.3, please do (and> thanks!). Please see> coding & contributing guidelines, of course. Also let me> know if you> need SVN account.>> Thanks,> Hans>>> Eric Fredj wrote:> > I forgot the main : I obviously made some specific> NestedSet builder> > for Base classes and Stub classes ...> >> > On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> <mailto:eofredj@g​mail.com>> > <mailto:eofredj at gmail dot com <mailto:eofredj@g​mail.com>>>​ wrote:> >> > Patch was made in mind to be integrated in main tree> because it> > requires some changes on the core:> >> > * database.xsd was updated to support some new> attributes in> > schema.xml> > o In fact, I replaced isTree by treeMode in> Table> > attribute to support several mode> > o I added some Column attribute to target> left and right> > fields> > * PropelOMTask.php was modified to managed the> new treeMode> > and call the new builder I added when needed> > * Column.php and Table.php to handle their new> attributes> > * OMBuilder.php to handle new attributes and> builder getter as> > it is done for Node builder> >> > Maybe the right way to share would be to create a> parallel> > 1.2-nestedset (or something else) branch in which I> could commit> > my job, improve it, fix it before you can merge it> with main 1.2> > officiel branch.> > Moreover, it could be more easy to develop the same> patch for 1.3> > then...> >> >> >> > On 12/18/06, *Hans Lellelid* < hans at velum dot net> <mailto:hans at velum dot net>> > <mailto: hans at velum dot net <mailto:hans@velu​m.net>>> wrote:> >> > Hi Eric,> >> > Depending on what it is you've been creating, I> think we can> > either add> > it to contrib or integrate it into main tree. My> preference> > would be to> > add it to the contrib directory in SVN. I can> get you an SVN> > account if> > you don't have one yet (please email offlist w/> desired username).> >> >> >>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> <mailto:dev-unsub​scribe at propel dot tigris​.org>> For additional commands, e-mail:> dev-help at propel dot tigris dot org <mailto:dev-help@​propel.tigris.org​>>>>>>

Ok, as promised, I made a patch on 1.3 branch in order to add NestedSetsupport.

I didn't commit it because, I am not currently satisfied.Indeed, it is fully usable but it requires to use a specific Stub andStubPeer in parallel with default ones.

So I decided to work now on an really integrated way to use NestedSet in atransparent way...

Now provided features:

- New builder to generate NestedSet object, peer and their stubs - Support for Iterator on NestedSet node in order to use it in a PreOrderTraversal way - Support for IteratorAggregate to retrieve right Iterator to use - Extended PropelPDO to add logging in prepare() method

On 12/18/06, Eric Fredj <eofredj at gmail dot com> wrote:>> Ok, I didn't take a look on 1.3 branch until now but I think I can adapt> the patch quickly.> I will try to produce before X-Mas.> By that time, I will attach the 1.2 patch on a Trac ticket when phpdb.orgwill be up :-)>> About coding guidelines, I tried to follow NodePeerBuilder* convention and> all I was able to read on Trac Wiki but feel free to comment and make> feedback ...>> PS :I asked for SVN account a few minutes ago ..>> Thx> ErIC>>> On 12/18/06, Hans Lellelid <hans at velum dot net> wrote:> >> > Hi Eric,> >> > Makes sense, ok. I think that this makes most sense in the 1.3 branch,> > as it would break 1.2 BC (and 1.3 is not far from being ready). So, if> > you want to create a ticket (or find that original ticket, if there is> > one) and commit this stuff to 1.3, please do (and thanks!). Please see> > coding & contributing guidelines, of course. Also let me know if you> > need SVN account.> >> > Thanks,> > Hans> >> >> > Eric Fredj wrote:> > > I forgot the main : I obviously made some specific NestedSet builder> > > for Base classes and Stub classes ...> > >> > > On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> > > <mailto:eofredj@g​mail.com>> wrote:> > >> > > Patch was made in mind to be integrated in main tree because it> > > requires some changes on the core:> > >> > > * database.xsd was updated to support some new attributes in> > > schema.xml> > > o In fact, I replaced isTree by treeMode in Table> > > attribute to support several mode> > > o I added some Column attribute to target left and right> > > fields> > > * PropelOMTask.php was modified to managed the new treeMode> > > and call the new builder I added when needed> > > * Column.php and Table.php to handle their new attributes> > > * OMBuilder.php to handle new attributes and builder getter as> > > it is done for Node builder> > >> > > Maybe the right way to share would be to create a parallel> > > 1.2-nestedset (or something else) branch in which I could commit> > > my job, improve it, fix it before you can merge it with main 1.2> > > officiel branch.> > > Moreover, it could be more easy to develop the same patch for 1.3> > > then...> > >> > >> > >> > > On 12/18/06, *Hans Lellelid* < hans at velum dot net> > > <mailto:hans@velu​m.net>> wrote:> > >> > > Hi Eric,> > >> > > Depending on what it is you've been creating, I think we can> > > either add> > > it to contrib or integrate it into main tree. My preference> > > would be to> > > add it to the contrib directory in SVN. I can get you an SVN> > > account if> > > you don't have one yet (please email offlist w/ desired> > username).> > >> > >> > >> >> > --------------------​--------------------​--------------------​---------> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> > For additional commands, e-mail: dev-help at propel dot tigris dot org> >> >>

Ok, I didn't take a look on 1.3 branch until now but I think I can adapt thepatch quickly.I will try to produce before X-Mas.By that time, I will attach the 1.2 patch on a Trac ticket whenphpdb.orgwill be up :-)

About coding guidelines, I tried to follow NodePeerBuilder* convention andall I was able to read on Trac Wiki but feel free to comment and makefeedback ...

PS :I asked for SVN account a few minutes ago ..

ThxErIC

On 12/18/06, Hans Lellelid <hans at velum dot net> wrote:>> Hi Eric,>> Makes sense, ok. I think that this makes most sense in the 1.3 branch,> as it would break 1.2 BC (and 1.3 is not far from being ready). So, if> you want to create a ticket (or find that original ticket, if there is> one) and commit this stuff to 1.3, please do (and thanks!). Please see> coding & contributing guidelines, of course. Also let me know if you> need SVN account.>> Thanks,> Hans>>> Eric Fredj wrote:> > I forgot the main : I obviously made some specific NestedSet builder> > for Base classes and Stub classes ...> >> > On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> > <mailto:eofredj@g​mail.com>> wrote:> >> > Patch was made in mind to be integrated in main tree because it> > requires some changes on the core:> >> > * database.xsd was updated to support some new attributes in> > schema.xml> > o In fact, I replaced isTree by treeMode in Table> > attribute to support several mode> > o I added some Column attribute to target left and right> > fields> > * PropelOMTask.php was modified to managed the new treeMode> > and call the new builder I added when needed> > * Column.php and Table.php to handle their new attributes> > * OMBuilder.php to handle new attributes and builder getter as> > it is done for Node builder> >> > Maybe the right way to share would be to create a parallel> > 1.2-nestedset (or something else) branch in which I could commit> > my job, improve it, fix it before you can merge it with main 1.2> > officiel branch.> > Moreover, it could be more easy to develop the same patch for 1.3> > then...> >> >> >> > On 12/18/06, *Hans Lellelid* < hans at velum dot net> > <mailto:hans@velu​m.net>> wrote:> >> > Hi Eric,> >> > Depending on what it is you've been creating, I think we can> > either add> > it to contrib or integrate it into main tree. My preference> > would be to> > add it to the contrib directory in SVN. I can get you an SVN> > account if> > you don't have one yet (please email offlist w/ desired> username).> >> >> >>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>>

Makes sense, ok. I think that this makes most sense in the 1.3 branch,as it would break 1.2 BC (and 1.3 is not far from being ready). So, ifyou want to create a ticket (or find that original ticket, if there isone) and commit this stuff to 1.3, please do (and thanks!). Please seecoding & contributing guidelines, of course. Also let me know if youneed SVN account.

Thanks,Hans

Eric Fredj wrote:> I forgot the main : I obviously made some specific NestedSet builder> for Base classes and Stub classes ...>> On 12/18/06, *Eric Fredj* < eofredj at gmail dot com> <mailto:eofredj@g​mail.com>> wrote:>> Patch was made in mind to be integrated in main tree because it> requires some changes on the core:>> * database.xsd was updated to support some new attributes in> schema.xml> o In fact, I replaced isTree by treeMode in Table> attribute to support several mode> o I added some Column attribute to target left and right> fields> * PropelOMTask.php was modified to managed the new treeMode> and call the new builder I added when needed> * Column.php and Table.php to handle their new attributes> * OMBuilder.php to handle new attributes and builder getter as> it is done for Node builder>> Maybe the right way to share would be to create a parallel> 1.2-nestedset (or something else) branch in which I could commit> my job, improve it, fix it before you can merge it with main 1.2> officiel branch.> Moreover, it could be more easy to develop the same patch for 1.3> then...>>>> On 12/18/06, *Hans Lellelid* < hans at velum dot net> <mailto:hans@velu​m.net>> wrote:>> Hi Eric,>> Depending on what it is you've been creating, I think we can> either add> it to contrib or integrate it into main tree. My preference> would be to> add it to the contrib directory in SVN. I can get you an SVN> account if> you don't have one yet (please email offlist w/ desired username).>>>

I forgot the main : I obviously made some specific NestedSet builder forBase classes and Stub classes ...

On 12/18/06, Eric Fredj <eofredj at gmail dot com> wrote:>> Patch was made in mind to be integrated in main tree because it requires> some changes on the core:>> - database.xsd was updated to support some new attributes in> schema.xml> - In fact, I replaced isTree by treeMode in Table attribute to> support several mode> - I added some Column attribute to target left and right> fields> - PropelOMTask.php was modified to managed the new treeMode and call> the new builder I added when needed> - Column.php and Table.php to handle their new attributes> - OMBuilder.php to handle new attributes and builder getter as it is> done for Node builder>> Maybe the right way to share would be to create a parallel 1.2-nestedset(or something else) branch in which I could commit my job, improve it, fix> it before you can merge it with main 1.2 officiel branch.> Moreover, it could be more easy to develop the same patch for 1.3 then...>>> On 12/18/06, Hans Lellelid <hans at velum dot net> wrote:> >> > Hi Eric,> >> > Depending on what it is you've been creating, I think we can either add> > it to contrib or integrate it into main tree. My preference would be to> > add it to the contrib directory in SVN. I can get you an SVN account if> >> > you don't have one yet (please email offlist w/ desired username).> >>>

Patch was made in mind to be integrated in main tree because it requiressome changes on the core:

- database.xsd was updated to support some new attributes in schema.xml - In fact, I replaced isTree by treeMode in Table attribute to support several mode - I added some Column attribute to target left and right fields - PropelOMTask.php was modified to managed the new treeMode and call the new builder I added when needed - Column.php and Table.php to handle their new attributes - OMBuilder.php to handle new attributes and builder getter as it is done for Node builder

Maybe the right way to share would be to create a parallel 1.2-nestedset (orsomething else) branch in which I could commit my job, improve it, fix itbefore you can merge it with main 1.2 officiel branch.Moreover, it could be more easy to develop the same patch for 1.3 then...

On 12/18/06, Hans Lellelid <hans at velum dot net> wrote:>> Hi Eric,>> Depending on what it is you've been creating, I think we can either add> it to contrib or integrate it into main tree. My preference would be to> add it to the contrib directory in SVN. I can get you an SVN account if> you don't have one yet (please email offlist w/ desired username).>

Another thing that you could do is put in a cron script that runs every minute and checks to see if the server is alive (or maybe it would check memory use) and then HUP apache appropriately. You could even do this without checks; just attempt a "graceful" first and if the server isn't up; issue a start". Graceful will restart apache in such a way that users don't notice (I forgot exactly how but basically it only restarts a server process that isn't handling requests, so it lets existing req's finish).

With UNIX servers, it's much better to stop processes from using too much memory early, because once the OS is out it starts killing things. So even if you get apache back up, you aren't sure what else was killed (and thus needs a restart). It may be logged somewhere of course, but still that's not the point.

Alan

On Dec 18, 2006, at 9:29 AM, Hans Lellelid wrote:

> Soenke Ruempler - NorthClick wrote:>> Hans Lellelid <mailto:hans at velum dot net> wrote on Monday, December >> 18, 2006>> 3:23 PM:>>>>>>>> I know that propel.phpdb.org has had a hard time staying online. I>>>> spent some time this weekend setting up Nagios for monitoring, but>>>> my configuration is still now working correctly. I may switch to>>>> a tool that I find easier to configure (e.g. OpenNMS), but for>>>> now, just ping me & I will restart Apache. I'm also going to look>>>> into limiting mod_python/Apache memory consumption, per Alan's>>>> suggestion.>>>>>>>> Yeah we've to restart our trac server each morning, too :D>>>> What could help is to lower the MaxRequestPerChild directive so >> childs are>> terminated after a specific number of requests. But I don't know >> if the>> memory allocation is per-child or global.>>> Ok, I'll try that out. I probably should also just cron an apache > stop> & start every AM.>> Hans>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>

Soenke Ruempler - NorthClick wrote:> Hans Lellelid <mailto:hans at velum dot net> wrote on Monday, December 18, 2006> 3:23 PM:>> >>> I know that propel.phpdb.org has had a hard time staying online. I>>> spent some time this weekend setting up Nagios for monitoring, but>>> my configuration is still now working correctly. I may switch to>>> a tool that I find easier to configure (e.g. OpenNMS), but for>>> now, just ping me & I will restart Apache. I'm also going to look>>> into limiting mod_python/Apache memory consumption, per Alan's>>> suggestion. >>> >> Yeah we've to restart our trac server each morning, too :D>> What could help is to lower the MaxRequestPerChild directive so childs are> terminated after a specific number of requests. But I don't know if the> memory allocation is per-child or global.> Ok, I'll try that out. I probably should also just cron an apache stop& start every AM.

>> I know that propel.phpdb.org has had a hard time staying online. I>> spent some time this weekend setting up Nagios for monitoring, but>> my configuration is still now working correctly. I may switch to>> a tool that I find easier to configure (e.g. OpenNMS), but for>> now, just ping me & I will restart Apache. I'm also going to look>> into limiting mod_python/Apache memory consumption, per Alan's>> suggestion.

Yeah we've to restart our trac server each morning, too :D

What could help is to lower the MaxRequestPerChild directive so childs areterminated after a specific number of requests. But I don't know if thememory allocation is per-child or global.

> I know that propel.phpdb.org has had a hard time staying online. I> spent some time this weekend setting up Nagios for monitoring, but my> configuration is still now working correctly. I may switch to a tool> that I find easier to configure (e.g. OpenNMS), but for now, just ping> me & I will restart Apache. I'm also going to look into limiting> mod_python/Apache memory consumption, per Alan's suggestion.>

If anyone knows how to limit mod_python memory, please let me know. Isee people asking about it, but haven't found an answer for how to dothat...

Depending on what it is you've been creating, I think we can either addit to contrib or integrate it into main tree. My preference would be toadd it to the contrib directory in SVN. I can get you an SVN account ifyou don't have one yet (please email offlist w/ desired username).

I know that propel.phpdb.org has had a hard time staying online. Ispent some time this weekend setting up Nagios for monitoring, but myconfiguration is still now working correctly. I may switch to a toolthat I find easier to configure (e.g. OpenNMS), but for now, just pingme & I will restart Apache. I'm also going to look into limitingmod_python/Apache memory consumption, per Alan's suggestion.

Thanks,Hans

Eric Fredj wrote:> Hi Folk,>>> I made some change on 1.2 branch to integrate new builders for Nested> Set generation support.> Until now, all is based on Joe Simms samples he provides in trac> attachment but it can surely be improved.> I think it can be reused on other branches without big changes but I> had to make it on 1.2 because it is the stable one used in our project.>> Where can I share my code and under which format (diff, svn commit on> specific branch) ?>> Is someone interested ?>> PS: some ideas why phpdb.org <http://phpdb.org> still down ? How can> we help ?>> ErIC>> On 12/17/06, * Eric Fredj* <eofredj at gmail dot com> <mailto:eofredj@g​mail.com>> wrote:>> I read "Nested Set Proposal" from Joe Simms thread started last> summer and I am very interested in it.> But it seems nothing changed for a few month.>> Is this still under conception/development ?> Is Joe Simms still among us ?>> I started to read proposed code and how Propel builders work in> order to create some NestedSet builder producing targeted sample> code provided in attached zip file.>> I retrieved SVN repository copy to make some changes and I work on> 1.2 branch.>> Someone else about NestedSet in Propel here ?>

I made some change on 1.2 branch to integrate new builders for Nested Setgeneration support.Until now, all is based on Joe Simms samples he provides in trac attachmentbut it can surely be improved.I think it can be reused on other branches without big changes but I had tomake it on 1.2 because it is the stable one used in our project.

Where can I share my code and under which format (diff, svn commit onspecific branch) ?

Is someone interested ?

PS: some ideas why phpdb.org still down ? How can we help ?

ErIC

On 12/17/06, Eric Fredj <eofredj at gmail dot com> wrote:>> I read "Nested Set Proposal" from Joe Simms thread started last summer and> I am very interested in it.> But it seems nothing changed for a few month.>> Is this still under conception/development ?> Is Joe Simms still among us ?>> I started to read proposed code and how Propel builders work in order to> create some NestedSet builder producing targeted sample code provided in> attached zip file.>> I retrieved SVN repository copy to make some changes and I work on 1.2branch.>> Someone else about NestedSet in Propel here ?>>