Hi Emil,

Thanks for your thoughts. Firstly, we plan to have BASE2 pointing out to the
internet, although the majority of people will access the data through our own
custom data summary pages which serve data visible to a 'webguest' account.
(We aim to make this software available.)

We currently do this in BASE1 and use the permission system to prevent
pre-publication data being served to the general public.  That's a bit limited
because we can only roll out *new* data to the public - if we wanted to update
existing public data in some way the dev/release approach wouldn't really
work.

I guess a combination of the permissions and mysqldump approaches would solve
most problems.  This way, pre-publication data would be on the main live
server, but wouldn't be visible to the public.  Yes, I think this works.
Problem solved hopefully!

cheers,
Bob

Emil Lundberg writes:
 > Hi Bob,
 > 
 > At the LCB, we've been running two or more parallel versions of BASE  
 > 2.x for ages, but only as far as BASE itself is concered. We DO have  
 > data export going on between two live 1.2.x installations, but this  
 > is due more to hardware constraints than added functionality, so the  
 > concept was scrapped for BASE 2.x.
 > 
 > We've never felt the need to make DATA part of the dev/release cycle,  
 > nor for a data release concept in general. It would certainly be  
 > interesting to hear your motivation for wanting to doing this though!
 > 
 > best,
 > 
 > /Emil
 > 
 > 
 > > Hi all,
 > >
 > > Has anyone got a pre-release or development server running in  
 > > parallel with a
 > > 'live' server?
 > >
 > > We would like to have dev, pre and live servers, and make data live  
 > > on some
 > > kind of release cycle.  In particular, I am wondering how we would  
 > > transfer
 > > data from pre to live.  I can see a few options:
 > >
 > > 1. database dump (e.g. mysqldump) from pre to live, however this  
 > > wouldn't
 > >    allow selective upgrading of data from 'pre' to 'live', which  
 > > would be
 > >    essential I think (papers/data awaiting publication would hold  
 > > back other
 > >    experiments).
 > >
 > > 2. some kind of migrator program - in the style of the base1->2  
 > > migrator,
 > >    including analysis steps
 > >
 > > 3. using batch loaders, load data from scratch on live server (and  
 > > re-run
 > >    analysis steps)
 > >
 > > any more ideas/thoughts?  much appreciated!
 > >
 > > cheers,
 > > Bob
 > >
 > > -- 
 > > Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
 > > Division of Cell and Molecular Biology | Imperial College London |
 > > Phone +442075941945 | Email [EMAIL PROTECTED]
 > 
 > -------------------------------------------------------------------------
 > This SF.net email is sponsored by: Splunk Inc.
 > Still grepping through log files to find problems?  Stop.
 > Now Search log events and configuration files using AJAX and a browser.
 > Download your FREE copy of Splunk now >>  http://get.splunk.com/
 > _______________________________________________
 > The BASE general discussion mailing list
 > basedb-users@lists.sourceforge.net
 > unsubscribe: send a mail with subject "unsubscribe" to
 > [EMAIL PROTECTED]

-- 
Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
Division of Cell and Molecular Biology | Imperial College London |
Phone +442075941945 | Email [EMAIL PROTECTED]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject "unsubscribe" to
[EMAIL PROTECTED]

Reply via email to