[Persistence-sig] persistence to code-related-object?

[Paolo Invernizzi]

Hello Jeremy,

JH> I suspect that transparently storing code in the database is an
JH> advanced topic that won't be addressed by the PEPs, although I'm happy
JH> to consider it if it ends up being an important requirement.

Yep, I think that the sig can reach a PEP without address this face of
the problem, still taking the door open for future expansions. What I
mean is "let's keep an eye on that, and let's avoid API
that would bring that problem not solvable."

JH> It is an important requirement for Zope, and we've got an incomplete
JH> version in the ZODB4 code base.

Yep. I've read Jeff mail, and I know ihook and Gordon's iu.py.
Actually for my project I've worked with Gordon's iu, and I've wrote an
import director for ZODB4 (indeed the installer in a whole is cool material!).

But as Jeff pointed out, the real "challenge" is the "reload"
abstraction/implementation.

Basically the "reload" is like a "commit" of modified code into an
existing application, but the big challenge of updating existing
instances of reloaded classes is left behind (as actually nothing
happens, existing instances are not affected).

If we apply persistent machinery to code-object, we can
begin to think of possible limited solution/problems to archive this
goal.

Jeremy, Am I loosing my time if I start playing around connection
implementation and cache?

-- 
Best regards,
 Paolo                            mailto:paoloinvernizzi@dmsware.com