Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-10-04 08:09:56 PDT
Message Hans Lellelid wrote:
> David Z├╝lke wrote:
>>> Isn't Sven saying that FETCH_INTO will keep memory/resource use to a
>>> minimum? (Unlike current situation where you would have a new object
>>> allocated for each row returned.)
>>
>> Right now, this is the case, but with iterators, the GC would kick in
>> sooner or later and free the memory. We'd need two fetch modes then, one
>> for iterators (default) and another for the oldschool array approach. Of
>> course, we could always add FETCH_INTO support should we discover that
>> PHP sucks and doesn't free the previously allocated memory (but come on,
>> what are the odds of PHP sucking, really? harhar)
>>
>
> Ok, fair enough. One thing to bear in mind is that in 1.3 & trunk we
> are also implementing the identify mapping for objects. I think this
> code is already in 1.3 -- and if not, it will be soon.
>
> The purpose of that, of course, is that we'd like
> retrieveByPK()/doSelect() to always return the same object instances if
> they've already been fetched. I'm assuming, though, that this will
> effectively prevent any GC of those objects. And I'm not sure what the
> FETCH_INTO implications would be ... but that might cause some crazy
> problems :)
>

It looks like this code has not been applied yet to 1.3 branch. What
the patch will do is modify populateObjects() method to first check for
a previously cached version of the object.

Obviously if we use Alan's approach to large object sets (which is also
what I do), this object caching will work fine (since no cache would be
created).

This was something that has been requested several times -- and I think
it makes sense -- so assuming there aren't any problems with this, I can
try to add that code in later today.

Hans