Re: [Zope-CMF] Re: five.intid and DirectoryView
Ross Patterson wrote at 2008-6-30 10:34 -0700: > ... >> Creating a savepoint seems to do the trick: >> > from persistent import Persistent > import transaction > app.pob = Persistent() > app.pob._p_oid is None >> True > s = transaction.savepoint() > app.pob._p_oid >> '\x00\x00\x00\x00\x00\x00E\xfa' > >Would that be a problem causing ZODB bloat? "savepoint" does not write to the main storage. The main storage is only modified after the final "commit". -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
Laurence Rowe <[EMAIL PROTECTED]> writes: > Ross Patterson wrote: >> Tres Seaver <[EMAIL PROTECTED]> writes: >> >>> Martijn Pieters wrote: On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: > "Martijn Pieters" <[EMAIL PROTECTED]> writes: >> But the code never does that. When cloning a file-based FSObject, a >> new instance is created and that is added to the ZODB. Noone else >> should do this either. > zope.app.keyreference does. The persistence machinery doesn't add an > object to a connection until commit. As such, an IPersistent and > IObjectAdded event handler, such as the one in zope.app.intid, that > needs the object to have a connection needs to add the object to a > connection. >>> Sounds like a bug in zope.app.intid to me: it shouldn't be forcing >>> objects to have connections. >>> Why is the IObjectAdded event fired at all? Perhaps that's the bug here. > Shouldn't anything that implements IPersistent be able to be added to a > connection? Wouldn't that be considered part of providing the > interface? Where else is an object that provides IPersistent stored in > global state? I assume it was easier at the time to use just one class. Perhaps this should be reconsidered now. However, just providing the IPersistence interface does not mean the object expects to be added to a connection arbitrarily. >>> Exactly. Nobody is supposed to add objects to a connection except their >>> already-persisted containers. >> >> That sounds right to me especially given that an object's parent isn't >> necessarily "where" the object is persisted. Shouldn't it be possible, >> for example, to have a container that looks up it's contained items from >> a utility that actually is stored in another ZODB. Such a container's >> items would not share their parent's connection. >> >> FWIW, this happens in zope.app.keyreference. The reason it needs the >> object to have a connection is so that it can get the object's _p_oid. >> If this is a bug, how can zope.app.keyreference get _p_oid for an object >> added in the current, as yet uncommitted transaction? > > Creating a savepoint seems to do the trick: > from persistent import Persistent import transaction app.pob = Persistent() app.pob._p_oid is None > True s = transaction.savepoint() app.pob._p_oid > '\x00\x00\x00\x00\x00\x00E\xfa' Would that be a problem causing ZODB bloat? Say if the object were deleted later in the same transaction? Would it slow down transactions adding large numbers of IPersistent objects? Can anyone else see any other potential problems with using savepoints instead of manually adding objects to a transaction? If my questions aboved are all resolved, should the implementation of zope.app.keyreference (and five.intid) be changed? Ross ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
Ross Patterson wrote: Tres Seaver <[EMAIL PROTECTED]> writes: Martijn Pieters wrote: On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: "Martijn Pieters" <[EMAIL PROTECTED]> writes: But the code never does that. When cloning a file-based FSObject, a new instance is created and that is added to the ZODB. Noone else should do this either. zope.app.keyreference does. The persistence machinery doesn't add an object to a connection until commit. As such, an IPersistent and IObjectAdded event handler, such as the one in zope.app.intid, that needs the object to have a connection needs to add the object to a connection. Sounds like a bug in zope.app.intid to me: it shouldn't be forcing objects to have connections. Why is the IObjectAdded event fired at all? Perhaps that's the bug here. Shouldn't anything that implements IPersistent be able to be added to a connection? Wouldn't that be considered part of providing the interface? Where else is an object that provides IPersistent stored in global state? I assume it was easier at the time to use just one class. Perhaps this should be reconsidered now. However, just providing the IPersistence interface does not mean the object expects to be added to a connection arbitrarily. Exactly. Nobody is supposed to add objects to a connection except their already-persisted containers. That sounds right to me especially given that an object's parent isn't necessarily "where" the object is persisted. Shouldn't it be possible, for example, to have a container that looks up it's contained items from a utility that actually is stored in another ZODB. Such a container's items would not share their parent's connection. FWIW, this happens in zope.app.keyreference. The reason it needs the object to have a connection is so that it can get the object's _p_oid. If this is a bug, how can zope.app.keyreference get _p_oid for an object added in the current, as yet uncommitted transaction? Creating a savepoint seems to do the trick: >>> from persistent import Persistent >>> import transaction >>> app.pob = Persistent() >>> app.pob._p_oid is None True >>> s = transaction.savepoint() >>> app.pob._p_oid '\x00\x00\x00\x00\x00\x00E\xfa' Laurence ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
Tres Seaver <[EMAIL PROTECTED]> writes: > Martijn Pieters wrote: >> On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: >>> "Martijn Pieters" <[EMAIL PROTECTED]> writes: But the code never does that. When cloning a file-based FSObject, a new instance is created and that is added to the ZODB. Noone else should do this either. >>> zope.app.keyreference does. The persistence machinery doesn't add an >>> object to a connection until commit. As such, an IPersistent and >>> IObjectAdded event handler, such as the one in zope.app.intid, that >>> needs the object to have a connection needs to add the object to a >>> connection. > > Sounds like a bug in zope.app.intid to me: it shouldn't be forcing > objects to have connections. > >> Why is the IObjectAdded event fired at all? Perhaps that's the bug here. >> >>> Shouldn't anything that implements IPersistent be able to be added to a >>> connection? Wouldn't that be considered part of providing the >>> interface? Where else is an object that provides IPersistent stored in >>> global state? >> >> I assume it was easier at the time to use just one class. Perhaps this >> should be reconsidered now. However, just providing the IPersistence >> interface does not mean the object expects to be added to a connection >> arbitrarily. > > Exactly. Nobody is supposed to add objects to a connection except their > already-persisted containers. That sounds right to me especially given that an object's parent isn't necessarily "where" the object is persisted. Shouldn't it be possible, for example, to have a container that looks up it's contained items from a utility that actually is stored in another ZODB. Such a container's items would not share their parent's connection. FWIW, this happens in zope.app.keyreference. The reason it needs the object to have a connection is so that it can get the object's _p_oid. If this is a bug, how can zope.app.keyreference get _p_oid for an object added in the current, as yet uncommitted transaction? Ross ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Pieters wrote: > On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: >> "Martijn Pieters" <[EMAIL PROTECTED]> writes: >>> But the code never does that. When cloning a file-based FSObject, a >>> new instance is created and that is added to the ZODB. Noone else >>> should do this either. >> zope.app.keyreference does. The persistence machinery doesn't add an >> object to a connection until commit. As such, an IPersistent and >> IObjectAdded event handler, such as the one in zope.app.intid, that >> needs the object to have a connection needs to add the object to a >> connection. Sounds like a bug in zope.app.intid to me: it shouldn't be forcing objects to have connections. > Why is the IObjectAdded event fired at all? Perhaps that's the bug here. > >> Shouldn't anything that implements IPersistent be able to be added to a >> connection? Wouldn't that be considered part of providing the >> interface? Where else is an object that provides IPersistent stored in >> global state? > > I assume it was easier at the time to use just one class. Perhaps this > should be reconsidered now. However, just providing the IPersistence > interface does not mean the object expects to be added to a connection > arbitrarily. Exactly. Nobody is supposed to add objects to a connection except their already-persisted containers. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZlfe+gerLs4ltQ4RAoGOAJ954hDazoOKVj7TZKJQX84wB0LRUwCgox23 rjY5Q3Xjhu+eDcVnmmzXdjs= =pF+8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
"Martijn Pieters" <[EMAIL PROTECTED]> writes: > On Thu, Jun 26, 2008 at 10:08 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: >> But since the FSObjects provide IPersistent, they can be added to a >> connection. If they're added to a connection, the object can be >> ghosted when that connection is closed. If another thread >> subsequently consults the DirectoryView registry for the same object, >> the persistnce machinery will raise ConnectionStateError when it >> tries to de-ghost the object from the closed connection. > > But the code never does that. When cloning a file-based FSObject, a > new instance is created and that is added to the ZODB. Noone else > should do this either. zope.app.keyreference does. The persistence machinery doesn't add an object to a connection until commit. As such, an IPersistent and IObjectAdded event handler, such as the one in zope.app.intid, that needs the object to have a connection needs to add the object to a connection. Shouldn't anything that implements IPersistent be able to be added to a connection? Wouldn't that be considered part of providing the interface? Where else is an object that provides IPersistent stored in global state? Ross ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
"Martijn Pieters" <[EMAIL PROTECTED]> writes: > On Thu, Jun 26, 2008 at 7:15 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: >>> I think because they are also used to create TTW skin objects; hit >>> 'customize' on one such object in the skins directory and a copy is >>> created that *is* persisted. >> >> So wouldn't that mean that DirectoryView should not store instances of >> FSObjects in a registry stored in global state and shared between ZODB >> connections? > > I don't see why not. Those stored in the global state are not the > persisted objects, only those loaded from filesystem files. But since the FSObjects provide IPersistent, they can be added to a connection. If they're added to a connection, the object can be ghosted when that connection is closed. If another thread subsequently consults the DirectoryView registry for the same object, the persistnce machinery will raise ConnectionStateError when it tries to de-ghost the object from the closed connection. Ross ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: five.intid and DirectoryView
"Martijn Pieters" <[EMAIL PROTECTED]> writes: > On Thu, Jun 26, 2008 at 5:26 AM, Ross Patterson <[EMAIL PROTECTED]> wrote: >> This seems wrong in that the object subclasses >> Persistent but is being used in a way that doesn't allow it to be stored >> in a ZODB. Why do the FSObject classes subclass Persistent? > > I think because they are also used to create TTW skin objects; hit > 'customize' on one such object in the skins directory and a copy is > created that *is* persisted. So wouldn't that mean that DirectoryView should not store instances of FSObjects in a registry stored in global state and shared between ZODB connections? Ross ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
