Thank you very much for the extensive answer, looking at the various
options I will most likely go for a script which will grab data from CSV
files. The source of the issue is not that I expect this to be rolled
out by a lot of people. Not at all actually, it's more that the database
the Pylons app will use needs to be up-to-date from the moment of
deployment. Once it is live it will update itself, but right now it
requires some manual work, meaning that the initial data will change
over time.

Thijs

On Fri, 26 Mar 2010 12:47 -0700, "Mike Orr" <[email protected]>
wrote:
> On Fri, Mar 26, 2010 at 12:09 PM,  <[email protected]> wrote:
> > Does Pylons (or SQLAlchemy in particular) have a method to load initial
> > data? Looking for something like what Django offers:
> > http://docs.djangoproject.com/en/1.1/howto/initial-data/#howto-initial-data
> >
> > Should this be dealt with in Pylons via the setup_app()? If so can
> > someone possible point my into a direction what the recommended way is
> > to initiate a app with a more-than-the-usual-test-data amount of initial
> > data (various tables, summing up to ~100 MB of raw SQL data).
> 
> setup_app() is the traditional way.  It's not necessarily the most
> appropriate way if you have a large amount of data. It works best for
> applications that are passed around or distributed publicly, so that
> anybody can install the app, run setup-app, and be ready to go.  But
> if you have a large amount of specific data, the issue of preserving
> the data becomes more important than conforming to the setup_app
> interface.
> 
> One issue with setup_app is that it can't take command-line arguments,
> so you can't make it do partial setups depending on the situation at
> hand; i.e., if you just want it to append data without dropping the
> existing tables. Although you can use environment variables as de
> facto arguments.
> 
> If you have the data already in the target database, or you have it in
> a way that you can copy it to the target database outside Pylons,
> maybe that's the best way to go. I built a Pylons app for an existing
> application that had been collecting data for a decade. I exported the
> data from FileMaker using CSV files, and used a utility script with my
> model to import the data. If I need to set up the app on another
> machine, I do a SQL dump of the live data and restore it on the target
> machine. I don't like setup_app because it's inflexible: it can only
> do one thing in a certain situation, usually setting up the database
> from scratch. And if carelessly run, it can delete data you meant to
> keep.  So I leave it as a do-nothing in most of my applications.  But
> if I had an application I were distributing publicly, I'd use it to
> make it easier for the recipient to initialize their app.
> 
> You can put standalone scripts in a scripts directory; I use
> myapp/scripts.  Then you can run them as "python -m
> myapp.scripts.myscript --myarg=myvalue".  Or you can make a "script"
> entry for them in setup.py, so that the installer will create a stub
> 'bin' program.  Or you can set up a Paster entry point, which would
> make it a new paster command ("paster my-setup-app --myarg=myvalue
> development.ini").  (But the command would only be listed if the
> current directory is the application directory, and you'd have to
> reinstall the app whenever you make changes that affect the entry
> points.)
> 
> The next issue that comes up with a standalone app is how to access
> the config data and initialize the model. ``paste.deploy.loadapp()``
> does that all in one step, but it may do too much.  (I.e.,
> initializing tables that don't exist, or reading cache data from
> tables that are empty).  So you may prefer to just pass the dburi as a
> command-line argument and call init_model() yourself, without going
> through loadapp() and load_environment().  It depends on the
> situation.
> 
> There is no equivalent to Django's data loaders. You would have to
> write code to do that yourself.
> 
> -- 
> Mike Orr <[email protected]>
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to