Heh no problem. I'll cc the list for you.So basically propel creates an object to represent each table in a DB. Foreign key relationships are maintained, and the propel objects cache the results.
So, in a simple scenario with "Account" and "Transactions", your "Account" object keeps an internal "collection" of transactions and each "transaction" keeps an internal reference to its "Account". There's the circular reference.
So, if you could explain your idea (a) as a solution to this architecture, that'd be great.
Also, why don't you describe (b) anyway just for fun :) Alan On Dec 9, 2005, at 5:35 PM, Andi Gutmans wrote:
Not cc:'ing internals@ because for some reason it doesn't seem to like me today (problem with our mail queue and lists.php.net) Well I didn't have an exact solution in mind because I don't know the exact problem you have and how you'd like to solve it. I was thinking of two ways: a) Doing some kind of id to object mapping (possibly using overloading __get/__set). b) Come to think of it, my (b), indirect references, isn't a good idea :)Andi At 10:24 AM 12/9/2005, David Zülke wrote:Would you mind explaining that "indirect property accessing" method, Andi? Or did you mean avoiding circular references altogether by having a third "intermediate" layer that would return the respective object when handed a GUID or something, so that effectively, one of the partners in the circle doesn't store the other partner directly, but just a unique identifier usind which you can retrieve it? (that's the way you have to do it in JavaScript if you don't want IE to crash due to memleaks when referencing from DOM elements to JS objects and vice versa) Thanks, - David Am 09.12.2005 um 18:08 schrieb Andi Gutmans:Sorry about that. I think it might be a problem with the server not my client. If it persists please let me know. At 08:37 AM 12/9/2005, Jochem Maas wrote:Andi - your email client seems to be leaking :-) Andi Gutmans wrote:Hi Alan, Generally speaking, if you create a circular reference (whether by reference or by value), then you will have a "memory leak" until the end of the request. This is not only true for objects (and circular references might be indirect) but also for arrays. This is a side-effect of reference counting systems, but within the way PHP is used within a request/response paradigm, it shouldn't be a real limiting factor in real-life usage. On the contrary, for these kind of apps, garbage collecting systems have potential to be significantly slower. Andi At 08:15 PM 12/7/2005, Alan Pinstein wrote:My question is closely related to the one discussed on this php-devthread: http://thread.gmane.org/gmane.comp.php.devel/32430 Someone just sent me this link, which I didn't find myself when searching b/c the searches strip "this" from queries. Anyway, the question is related to reference counting of objects whenassigned by value and by reference. It is a very important OO topicas the ability to have a non-ref-counted object "handle" is basically requisite to prevent circular reference deadlocks in OO projects.If the way I have proposed doesn't work, then what is the officialway? And there *must* be one, otherwise, there is no way to avoid huge memory leaks (deferred release until end-of-script, I know, butit's a memory leak in the context of the script while it's running)with this kind of OO arrangement.In particular what confuses me is, why does, at least on PHP 5.0.4,this: $obj = &$this->this; // doesn't seem to increment the refcount of the object behaves differently from: $obj = &$this; // does seem to increment the refcount to the object References to $this should not only be valid, but are pretty muchrequired for proper memory management in an OO environment, unless there is some other sanctioned way to get a weak reference... now Iam not sure if the fact that making a & reference to an object doesn't increment the refcount is intended behavior, or an unintended side effect that may change. This is one of my major questions. Also, in regards to the thread linked above, I'd say that making& $this an error is not desirable behavior; but maybe changing thevalue of $this should be (ie in C terms, $this is not an lvalue). Although, in C++/Obj-C you *can* even change this/self... in fact it's common in Obj-C: - (id) init { if (self = [super init]) { /* etc */ } return self; }Of course PHP is not Obj-C, but it's OO and garbage collected in a similar way, so PHP has the same need for manipulating $this; thatis, creating weak references. Alan On Dec 7, 2005, at 11:27 AM, Antony Dovgal wrote:On 07.12.2005 18:40, Alan Pinstein wrote:Hi all-<skip> Please use php-general@lists.php.net for questions regarding development *in* PHP. -- Wbr, Antony Dovgal-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
