[storm] why weakrefdict for cache?

[Bernd Dorn]

On 31.08.2007, at 16:46, Gustavo Niemeyer wrote:

> Hey Bernd!
>
hi gustavo, we started to use storm in our books portal

> Good to see you around.  Was just talking about the memorable
> sprint you guys have had with Sidnei da Silva. :-)
>

hehe, nice to hear :-)

>> imho the memory consumption problem could be handled with explicit
>> deallocation of objects
>
> You can't deallocate the object explicitly if there is a strong
> reference being held in a cache dictionary.

hm what about:

in store init:
store._kept = set()

when an object is loaded:
store._kept.add(obj_info.get_obj())

on commit or rollback:
store._kept.clear()

to remove the ref somewhere else:
store._kept.discard(somestormobjwehaveinlocals)

and the store._cache stays as it is

>
> In any case, I understand the points of both of you. I think the
> bottom line is that we can't simply use a strong reference
> dictionary, and a cache implementation which holds objects only
> while there are other references may be suboptimal in some
> cases.
>
> The solution for both issues is simple: we need a slightly smarter
> cache implementations which is able to hold, say, the N last used
> objects. This is easy to implement and integrate, and is likely
> to be added in the near future.
>

yes, the above set could be a set/list with a maximum objects that  
automatically pops out old ones

>
>> that's a god point ... even though i am not sure in which use-case  
>> one
>> should store an object in memory which may magically change its  
>> values
>> without getting the object from a specific place again explicitly
>
> As an example, the following will fail, even though it must work,
> otherwise whenever a transaction is committed all the references
> to objects alive are lost.
>
> person = store.get(Person, 1)
> person.name = "Bob"
> store.commit()
> assert store.get(Person, 1) is person
>

i see, probably it would be best to implement the hard refs in the  
zope datamanager and make it a parameter e.g: keepRefs


> -- 
> Gustavo Niemeyer
> http://niemeyer.net