Ben Sizer schrieb:
I can't see a way to get my database to change when my model changes.
tg-admin sql update seems to require some external script to be
written, and the only other alternative seems to be dropping and
recreating the tables. Catwalk silently breaks when you load it up with
an altered model file, so that's no help.
Surely amending the model is a crucial activity that is going to be
performed many times during development? In my 10 years of using
relational databases, I can't think of a single non-trivial application
that didn't need to add a column at some point without clearing out the
database.
Is there at least a simple way to dump out the data and re-import it?
Or perhaps some way of knowing what column declaration a given model
attribute will require?
There is nothing beyond what you already know: carefully writing
migration scripts on the SQL-level.
It might be possible to come up with schemes for simple
table-alterations like added/removed primitive columns/properties.
But especially the edges of the object graph are a complicated matter,
and will always require special attention by a programmer who deeply
knows the model.
The only question arises if this is better done in Python - working with
the model itself somehow - or in SQL. I prefer the latter for two reasons:
- writing a model that somehow can adapt older data to newer
structures is complicating the model itself, introducing potentially
more bugs.
- it exists a clean text-only-based representation of SQL, that can be
subject of e.g. scripted alterations of DB-dumps.
But of course using python & SQL together is the most powerful
combination: instead of shoehorning certain logic-dependent alterations
into SQL (NVL anyone?) is horrible, better use a mixture of pure DB-api
calls and python-code.
All these problem only occur - to me at last - in productive
environments though! Because for development, the power of python allows
me to easily create a script that sets up the wiped clean DB after a
model-change into a well-defined state containing test-data. For
example, I write lists like this:
defaultdata = [
{ 'class' : MyModelClass,
'params' : {
'name' : 'value',
},
'handle' : 'something'
}
]
I then can take each entry in this list and create the object by a simple
data['class'](**data['params'])
Some thought has to be given to relations in this scheme, which I
usually do by stuffing away the created object keyed with its handle or
type/handle, so that later objects can refer to it.
Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
