durusmail: durus-users: volatile variables vs. ComputedAttribute
volatile variables vs. ComputedAttribute
2006-02-06
2006-02-06
2006-02-06
2006-02-06
volatile variables vs. ComputedAttribute
David Binger
2006-02-06
On Feb 6, 2006, at 10:56 AM, Jeff Bauer wrote:

> Does Durus have anything equivalent to ZODB's
> volatile "_v_" variables?
>
> I'm aware of ComputedAttribute, which I assume
> is the near-equivalent of ZODB's version.
>
> Here's a contrived example of something I'd like
> to do:
>
>     class MostlyHarmless(Persistent):
>         def set_connection(self, connection)
>             self._v_connection = connection
>
> It would be convenient during the process lifetime
> for MostlyHarmless to have a connection attribute,
> but it obviously can't be stored.

In my opinion, convenience attributes on
Persistent instances like this invite trouble.

>
> If this is not possible, I suppose an alternative
> would be to have connection available as a global
> or a module singleton and do something like this:
>
>     import PlanetEarth
>
>     class MostlyHarmless(Persistent):
>
>         def _connection(self):
>             return PlanetEarth.connection
>         connection = ComputedAttribute(_connection)
>
> Is this a proper Durus-ish approach?

I don't think so.
ComputedAttributes exist so that invalidations can be
propagated to other clients, and you would not have any
thing to compute or invalidate here.

Other options:

You might get away with putting the _v_connection
attribute on the class, if you really want self._v_connection
to work.

If you are always dealing with instances that have already
been committed to the database, you could use the
self._p_connection value, which is already there.

My personal preference is to have a global get_connection()
that returns the value of a name in a module variable.




reply