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.
