[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Re: Change management



On Thu, 2012-07-26 at 16:38 +0200, Jan Ploski wrote:
> Hi Tim,
> 
> Thanks for the quick reply.
> 
> It's a relief to hear that only a few configuration items are stored in 
> the database - please keep it that way!
> 
> IIRC, db attributes for custom fields also need to be created manually, 
> so there is need for some synchronization mechanism dev->production. 
> Anything else that comes to mind?

In current releases (except where I broke it ...) custom fields created
through the GUI are only in the database during creation. When you
"commit" they're written to a file and removed from the db.

If you mean the db columns for new fields need to be created, you are
correct. That means if you're migrating devel -> live you will need to
do:
./bin/epadmin update [archiveid]

/Tim.

> Tim Brody wrote:
> > On Thu, 2012-07-26 at 16:04 +0200, Jan Ploski wrote:
> >> Hi,
> >>
> >> Is there a comprehensive list of which EPrints configuration details are
> >> stored in the file system and which in the database? Are all
> >> configuration settings stored in the database exportable/importable
> >> to/from the file system?
> >>
> >> Background: although little tweaks via GUI may seem appealing for small
> >> installations, in general they sound like asking for trouble. Ideally,
> >> I'd like to have all configuration changes pass through version control
> >> and also through a staging (test) system. This is required for
> >> documentation and also for signing off changes by the client before they
> >> are brought into production. Is anyone else using EPrints in this
> >> manner? Are there recommended administration practices (except for
> >> "backup before changes" - restoring backups may be quite problematic if
> >> the data moves forward after changes)? Or is everyone just crossing
> >> their fingers and tweaking their production EPrints directly?
> >
> > Hi,
> >
> > There are no configuration settings stored in the database, except for:
> >
> >   - the subjects tree
> >   - individual user settings
> >
> > The sensible approach is to store all of your configuration in a
> > revision control system (svn or similar). That is, everything below
> > archives/[archiveid]/cfg/. This can be periodically committed to reflect
> > any changes made via the GUI.
> >
> > Larger sites will tend to have a development instance and a live
> > instance, with these reflected in different branches of your RCS.
> >
> > And of course, you will want to have a backup strategy for the system as
> > a whole (the contents + database).
> >
> >
> >
> >
> > *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> > *** Archive: http://www.eprints.org/tech.php/
> > *** EPrints community wiki: http://wiki.eprints.org/
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20120726/0777b3fb/attachment.bin