[Zope-Coders] Creating a "default" error_log object

Chris McDonough chrism@zope.com
Thu, 18 Jul 2002 11:22:45 -0400


> -1 on adding any more magic to 'upgrade' an existing database.
>
> +1 on adding one when the database is first created.

Yeah, upgrading an existing installation with 'default' objects for
new releases that were not 'default' in the past should be an
explicit step.  It's terribly annoying to have somebody "upgrade"
your database behind your back.

But on the other end of the spectrum we need some way of allowing
people who "just want to upgrade" and dont necessarily know much
about the gory details of default object initialization to take this
step.

I propose this:

- first of all, get rid of Data.fs.in.  It's dead, Jim.  The
  application init code does it all anyway.

- Second of all, create all "deletable" default objects only when
  populating a brand new database.  Change default initialization to
  write a  single flag out to signify that the deletable default
  elements have been created (the whole lot of them, sessions,
examples,
  standard "methodish" objects, etc).  This flag signifies a
terminal
  state for deletable default object creation -- once it is written,
  Zope initialization will never attempt to create future
  default objects within this database, even when a user upgrades to
  the latest Zope version.

- Add a method with a well-known name on the application object to
  "upgrade" to the latest default object scheme.  Document this
method.

Alternately, add yet another magic environment variable or z2.py
flag to signify that you want to upgrade your default objects. ;-)

Anybody have a better idea?

- C