views:

294

answers:

3
+2  Q: 

python orm

This is a newbie theory question - I'm just starting to use Python and looking into Django and orm. Question: If I develop my objects and through additional development modify the base object structures, inheritance, etc. - would Django's ORM solution modify the database automatically OR do I need to perform a conversion (if the app is live)?

So, I start with a basic Phone app Object person: name, address, city, state, zip, phone and I change to Object person: title, name, address, city, state, zip, phone object Object phone: type, phone #

Do I manually convert via the db and change the code OR does the ORM middleware make the change? and if so - how?

+4  A: 

The Django book covers this issue in Chapter 5, near the end of the chapter (or bottom of the page, in the web edition). Basically, the rules are:

  • When adding a field, first add it to the database manually (using, e.g., ALTER TABLE) and then add the field to the model. (You can use manage.py sqlall to see what SQL statement to execute.)
  • When removing a field, remove it from your model and then execute the appropriate SQL statement to remove the column (e.g., an ALTER TABLE command), and any join tables that were created.
  • Renaming a field is basically a combination of adding/removing fields, as well as copying data.

So to answer your question, in Django's case, no, the ORM will not handle modifications for you -- but they're not that hard to do. See that chapter of the book (linked above) for more info.

mipadi
+4  A: 

As of Django 1.02 (and as of the latest run-up to 1.1 in subversion), there is no automatic "schema migration". Your choices are to drop the schema and have Django recreate it (via manage.py syncdb), or alter the schema by hand yourself.

There are some tools on the horizon for Django schema migration. (I'm watching South.)

Dave W. Smith
I'm using South, not just watching it, and it's a much better option than "drop the schema and have Django recreate it" or "alter the schema by hand yourself."
Carl Meyer
A: 

We include a 'version' number in the application name.

Our directories look like this

project
    settings.py
    appA_1
        __init__.py
        models.py
        tests.py
    appB_1 
        __init__.py
        models.py
        tests.py   
    appB_2
        __init__.py
        models.py
        tests.py

This shows two versions of appB. appB_1 was the original version. When we changed the model, we started by copying the app to create appB_2, and then modified that one.

A manage.py syncdb will create the fresh new appB_2.

We have to unload and reload the tables by copying from appB_1 to appB_2. Once.

Then we can remove appB_1 from the settings.py. Later we can delete the tables from the database.

S.Lott
-1 This is a really cumbersome solution compared to using either raw SQL migrations or a tool like django-evolution or South. I wouldn't recommend it for anyone starting out.
Carl Meyer