Is it rude to ask why not disable the weakidentity map?
Under the turbogears web framework, our Sessions only exist for the
duration of the service call, and I am finding myself appending all
these objects to a no_garbage_collect list that I am keeping on the
session object anyway.
Then the
On May 1, 2010, at 10:18 AM, Kent wrote:
Is it rude to ask why not disable the weakidentity map?
Under the turbogears web framework, our Sessions only exist for the
duration of the service call, and I am finding myself appending all
these objects to a no_garbage_collect list that I am
If it is a feature you'd prefer to eventually get rid of, I will not
use it. You are correct that not *everything* that is fetched do I
need a strong ref to.
You said:
There's no problem with the strong map other than its a configuration
switch that adds to potential confusion, and when in
On May 1, 2010, at 12:41 PM, Kent wrote:
If it is a feature you'd prefer to eventually get rid of, I will not
use it. You are correct that not *everything* that is fetched do I
need a strong ref to.
You said:
There's no problem with the strong map other than its a configuration
switch
What's strange is that I can't recreate the problem on more simple
stage. Every time I refresh() on the parent object, the list objects
remain the same. In other words, *sometimes* it behaves as I hope it
to (by apparently refreshing the list's objects) and *sometimes* if
throws them out and
refresh doesn't remove any objects from the session so its a matter of
what is present in the session, not marked as dirty, and strongly
referenced on the outside. if you're using refresh you shouldn't care
about how it gets data back into the collection.
Kent wrote:
What's strange is that I
I agree I shouldn't care, so maybe there is another way to attack my
problem. The reason I care is because I've extended the python object
with some auxiliary information that I need. After the refresh() in
this case, I still need access to that data that is tied to the
object, but not present
Kent wrote:
I agree I shouldn't care, so maybe there is another way to attack my
problem. The reason I care is because I've extended the python object
with some auxiliary information that I need. After the refresh() in
this case, I still need access to that data that is tied to the
object,
Conor wrote:
Kent wrote:
I agree I shouldn't care, so maybe there is another way to attack my
problem. The reason I care is because I've extended the python object
with some auxiliary information that I need. After the refresh() in
this case, I still need access to that data that is
Thanks... that is very helpful. I could keep references to these. If
I choose the apparently lazier route and set weak_identity_map=False,
then does any other action besides explicitly expunging free this
memory, such as when the session goes out of scope, I assume?
Or do I need to carefully
Kent wrote:
Thanks... that is very helpful. I could keep references to these. If
I choose the apparently lazier route and set weak_identity_map=False,
then does any other action besides explicitly expunging free this
memory, such as when the session goes out of scope, I assume?
Or do I need
Ok, I wonder the reasons, but I trust your answer completely, so I
won't disable it. Thanks for your help again.
On Mar 4, 4:26 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
Thanks... that is very helpful. I could keep references to these. If
I choose the apparently lazier
12 matches
Mail list logo
