[ZODB-Dev] BTrees and Mutables, was Re: [IndexedCatalog] bug in default indexing

[Casey Duncan]

On Tuesday 11 February 2003 04:04 pm, Christian Reis wrote:
> On Tue, Feb 11, 2003 at 03:24:05PM -0500, Shane Hathaway wrote:
> > Casey Duncan wrote:
> > > An alternative which is perhaps more palatable is to just set the w=
hole=20
> > > mutable object into the btree again. Like:
> > >=20
> > > l =3D tree['bar']
> > > l.append(4)
> > > tree['bar'] =3D l # Trigger list persistance
> >=20
> > In fact, if you put simple lists in BTrees, you have to use this=20
> > pattern.  Setting tree._p_changed will not get the right object store=
d.=20
>=20
> Whoa. You mean to say that:
>=20
>     l =3D tree['bar']
>     l.append(4)
>     tree['bar'] =3D l
>=20
> is *not* the same as:
>=20
>     tree['bar'].append(4)
>=20
> right? And the first form *does* work as expected, or are there
> side-effects?

The side affect is that the new list value is persisted. Otherwise it isn=
't=20
(as in the 2nd example) and the next time it is loaded from the database =
the=20
list will not contain 4.

As Shane mentioned, you probably should store non-persistent mutable obje=
cts=20
in BTrees at all.

For instance, If this is a short list of unique integer values, then use =
an=20
IISet, which is mutable and persistent. If it is a really long list then =
use=20
an IITreeSet. Otherwise use a tuple which cannot be mutated in place.

-Casey