headers
Tristan Rivoallan | 2 May 2007 10:17
Favicon

symfony nested set licence

Hi,

i'm the maintainer of symfony's sfPropelActAsNestedSetBehaviour plugin.

Fabien (from symfony) pointed me to this thread :
http://propel.tigris.org/servlets/ReadMsg?list=dev&&msgNo=2493

the plugin code is indeed based on code from joesims and heltem.

authors are mentionned in plugin's docblocks :
http://www.symfony-forge.com/sfPropelActAsNestedSetBehaviorPlugin/docs/-sep-__filesource-sep-fsource_sfPropelActAsNestedSetBehaviorPlugin__libsfPropelActAsNestedSetBehavior.class.php.html

is it ok for you if i change plugin's licence to lgpl ? if so, i'll
take care of that as soon as i get an svn access.

anyway, i'll contribute all that back to propel as soon as 1.3 is released.

regards,

tristan
Permalink | Reply | 3 comments |
headers
Hans Lellelid | 2 May 2007 12:58

Re: symfony nested set licence

Hi Tristan,

Thanks for contacting the list.  Others (David?) may have some 
additional comments or feedback, but I think that changing the license 
of the software to LGPL is appropriate.  As I understand it, Symfony 
uses a BSD license, which is less restrictive than our LGPL.  So, code 
that is based on code contributed to Propel under the LGPL needs to be 
LGPL (or I suppose a more restrictive license also works).

We definitely support sharing code, but we do want to make sure it's 
done in a way that respects the principles of open-source software.

Thanks,
Hans

Tristan Rivoallan wrote:
> Hi,
> 
> i'm the maintainer of symfony's sfPropelActAsNestedSetBehaviour plugin.
> 
> Fabien (from symfony) pointed me to this thread :
> http://propel.tigris.org/servlets/ReadMsg?list=dev&&msgNo=2493
> 
> the plugin code is indeed based on code from joesims and heltem.
> 
> authors are mentionned in plugin's docblocks :
>
http://www.symfony-forge.com/sfPropelActAsNestedSetBehaviorPlugin/docs/-sep-__filesource-sep-fsource_sfPropelActAsNestedSetBehaviorPlugin__libsfPropelActAsNestedSetBehavior.class.php.html 
> 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tristan Rivoallan | 2 May 2007 13:08
Favicon

Re: symfony nested set licence

On 5/2/07, Hans Lellelid <hans <at> velum.net> wrote:

> Thanks for contacting the list.  Others (David?) may have some
> additional comments or feedback, but I think that changing the license
> of the software to LGPL is appropriate.  As I understand it, Symfony
> uses a BSD license, which is less restrictive than our LGPL.  So, code
> that is based on code contributed to Propel under the LGPL needs to be
> LGPL (or I suppose a more restrictive license also works).

ok. i will wait until tomorrow for further comments and then change
plugin's licence.

> We definitely support sharing code, but we do want to make sure it's
> done in a way that respects the principles of open-source software.

could not agree more :)

regards,

tristan

ps : symfony's licence is MIT
Permalink | Reply | 1 comment |
headers
Tomasz P. Kotecki | 3 May 2007 12:20

object instance pooling

Hi guys,

I think we've found a problem with the instance pooling implementation.

Basically when we ran some long-running cron job we experienced
something that looked like memory leak. Obviously, it turned out to be
the instance pooling mechanism that was keeping all the instances we
ever instantiated during the batch. So we've fixed it by runnning
clearInstancePool() on every peer class that's involved.

But that's a short-term solution, since as the code grew, we obviously
need to keep track of the involved peer classes. That's not very scalable.

At this point I thought it should be possible to disable instance
pooling altogether at runtime (since in most cases you do want them to
be pooled). I think such an option was mentioned once when the feature
was in the "todo" stage, but I can't find any way to enable it.

The implementation, I think, could be as easy as:

<code>
public static function addInstancePool($obj)
{
  if (Propel::keepInstancePool())
  {
    // the code that's currently there
  }
}
</code>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cameron Brunner | 3 May 2007 23:06
Picon

Re: object instance pooling

I must admit i had considered extending this functionality as well, i
hit the same issues in a couple dummy data scripts i wrote, tho i
hadn't decided where things had to be put etc as yet.

If things are calling it directly instead of using methods that exist
(do the methods that are needed exist? i dont remember) then it should
be changed.

+1 for adding this support in some way

On 5/3/07, Tomasz P. Kotecki <tomek <at> realtsp.com> wrote:
> Hi guys,
>
> I think we've found a problem with the instance pooling implementation.
>
> Basically when we ran some long-running cron job we experienced
> something that looked like memory leak. Obviously, it turned out to be
> the instance pooling mechanism that was keeping all the instances we
> ever instantiated during the batch. So we've fixed it by runnning
> clearInstancePool() on every peer class that's involved.
>
> But that's a short-term solution, since as the code grew, we obviously
> need to keep track of the involved peer classes. That's not very scalable.
>
> At this point I thought it should be possible to disable instance
> pooling altogether at runtime (since in most cases you do want them to
> be pooled). I think such an option was mentioned once when the feature
> was in the "todo" stage, but I can't find any way to enable it.
>
> The implementation, I think, could be as easy as:
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Zülke | 4 May 2007 11:44

Re: symfony nested set licence

sounds good. thanks for the prompt action.

cheers,

David

Am 02.05.2007 um 13:08 schrieb Tristan Rivoallan:

> On 5/2/07, Hans Lellelid <hans <at> velum.net> wrote:
>
>> Thanks for contacting the list.  Others (David?) may have some
>> additional comments or feedback, but I think that changing the  
>> license
>> of the software to LGPL is appropriate.  As I understand it, Symfony
>> uses a BSD license, which is less restrictive than our LGPL.  So,  
>> code
>> that is based on code contributed to Propel under the LGPL needs  
>> to be
>> LGPL (or I suppose a more restrictive license also works).
>
> ok. i will wait until tomorrow for further comments and then change
> plugin's licence.
>
>> We definitely support sharing code, but we do want to make sure it's
>> done in a way that respects the principles of open-source software.
>
> could not agree more :)
>
> regards,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Zülke | 4 May 2007 11:45

Re: object instance pooling

+1

Am 03.05.2007 um 23:06 schrieb Cameron Brunner:

> I must admit i had considered extending this functionality as well, i
> hit the same issues in a couple dummy data scripts i wrote, tho i
> hadn't decided where things had to be put etc as yet.
>
> If things are calling it directly instead of using methods that exist
> (do the methods that are needed exist? i dont remember) then it should
> be changed.
>
> +1 for adding this support in some way
>
> On 5/3/07, Tomasz P. Kotecki <tomek <at> realtsp.com> wrote:
>> Hi guys,
>>
>> I think we've found a problem with the instance pooling  
>> implementation.
>>
>> Basically when we ran some long-running cron job we experienced
>> something that looked like memory leak. Obviously, it turned out  
>> to be
>> the instance pooling mechanism that was keeping all the instances we
>> ever instantiated during the batch. So we've fixed it by runnning
>> clearInstancePool() on every peer class that's involved.
>>
>> But that's a short-term solution, since as the code grew, we  
>> obviously
>> need to keep track of the involved peer classes. That's not very
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hans Lellelid | 4 May 2007 12:16

Re: object instance pooling

I agree too.  Tomasz, would you mind opening a ticket with the problem & 
your suggested fix?

Thanks,
Hans

David Zülke wrote:
> +1
> 
> 
> 
> 
> Am 03.05.2007 um 23:06 schrieb Cameron Brunner:
> 
>> I must admit i had considered extending this functionality as well, i
>> hit the same issues in a couple dummy data scripts i wrote, tho i
>> hadn't decided where things had to be put etc as yet.
>>
>> If things are calling it directly instead of using methods that exist
>> (do the methods that are needed exist? i dont remember) then it should
>> be changed.
>>
>> +1 for adding this support in some way
>>
>> On 5/3/07, Tomasz P. Kotecki <tomek <at> realtsp.com> wrote:
>>> Hi guys,
>>>
>>> I think we've found a problem with the instance pooling implementation.
>>>
>>> Basically when we ran some long-running cron job we experienced
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tomasz P. Kotecki | 4 May 2007 12:46

Re: object instance pooling

Done. Let me know what you think.

http://propel.phpdb.org/trac/ticket/420

-- 
regards,
Tomasz P. Kotecki

> I agree too.  Tomasz, would you mind opening a ticket with the problem &
> your suggested fix?
> 
> Thanks,
> Hans
> 
> David Zülke wrote:
>> +1
>>
>>
>>
>>
>> Am 03.05.2007 um 23:06 schrieb Cameron Brunner:
>>
>>> I must admit i had considered extending this functionality as well, i
>>> hit the same issues in a couple dummy data scripts i wrote, tho i
>>> hadn't decided where things had to be put etc as yet.
>>>
>>> If things are calling it directly instead of using methods that exist
>>> (do the methods that are needed exist? i dont remember) then it should
>>> be changed.
>>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hans Lellelid | 4 May 2007 12:56

Re: object instance pooling

That looks great -- thank you!

Hans

Tomasz P. Kotecki wrote:
> Done. Let me know what you think.
> 
> http://propel.phpdb.org/trac/ticket/420
>
Permalink | Reply | 0 comments |

Gmane