[Pkg-zope-developers] Bug#354941: zope3-sandbox: problem seems caused by default values; suggest fixing

[Fabio Tranchitella]

Hi Ross,

Il giorno mer, 29/03/2006 alle 16.24 -0800, Ross Boylan ha scritto:
> > By the way, the only (standard) reason to have an old sandbox instance
> > is a broken installation of the package (or a manually created one).
> 
> That puzzles me.  Doesn't the installation of the  package create the
> sandbox instance?  I thought that was the whole point.  So this means
> that whenever you upgrade the package you have an already existing
> instance.

No, read again: "a broken installation of the package (which is your
case) or a manually created instance without data". If you upgrade the
package, it should be smart enough to check if the instance has been
already created.

> Or maybe I'm not understanding what you mean by "old" sandbox.  I'm
> interpreting it as meaning "the sandbox created by an earlier version
> of zope3-sandbox."  The "new" one is the one the current version being
> installed wants to create.

No, you are wrong. With "old" sandbox I mean a broken instance without
data. When you create a zope instance, it contains no data untill you
start it the first time. Note that the package automatically starts the
instance after the creation, so a working zope-sandbox's instance
without data is something which won't exist.

> One of my concerns is  that if you install the package (zope3-sandbox)
> and later upgrade it, without touching the defaults, it should "just
> work." I think that's hard to achieve here.  If you refuse to
> upgrade, you get the problem seen here.  If you delete the old
> instance, you may delete some working data, the concern you have in
> mind.  You could create a new instance, e.g., sandbox2, but the
> proliferation of instances doesn't seem very desirable either.

sandbox package upgrades without problem, AFAIK.

> Can an existing instance be upgraded in place?

It hasn't to be upgraded at all, all the source code is external to the
instance.

> I don't follow why ZEO vs ZODB matters.  Every instance has a
> database, I think.  I also think the database would have something in
> it, even if the user hadn't added anything.

You are wrong: zope-sandbox's instances are *with data*, because they
use ZODB, but the user could have created by hand a his own instance
called sandbox which is without data, because it uses ZEO, and this is
why that 'abort' is there.

> Better errors would be a big help.
> [...]
> Thanks for the tip.  That might be good to put in the error message,
> or README.Debian.

I'll include that with the next upload.

> If it were possible to identify cases in which the user hadn't done
> anything, I think it would be reasonable to blow them away silently.
> As I've said, I'm not sure how that could be done.  Maybe something as
> crude as storing the time-stamp of the database file immediately after
> setup would do.  I'm not sure if there could be changes (e.g., product
> installations) that didn't affect the database....

I have no idea on how this could be achieved.

> > Thanks for your suggestion,
> > 
> Thanks for you work on the package, and for taking the time to explain
> things to me.

You're welcome, and sorry if my english isn't good enough to explain you
what the facts are. :)

-- 
Fabio Tranchitella <kobold at debian.org>                        .''`.
Proud Debian GNU/Linux developer, admin and user.            : :'  :
                                                             `. `'`
   http://people.debian.org/~kobold/                           `-
_____________________________________________________________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://lists.alioth.debian.org/pipermail/pkg-zope-developers/attachments/20060330/50ced381/attachment.pgp