Thanks. I haven't heard of Django Evolution. Just searched for it on Google; it sounds exactly like what I'm looking for. In the meantime, I've found 'python manage.py inspectdb <application>' which helps a lot. It seems to general model classes by inspecting the DB the app. is connected to in settings.py. This helps a lot, both as a learning tool for how to write model classes, and as a way of putting in a correct class if you tend to do things the way I do, i.e. backwards... SQL heavy. I think I'll give Django Evolution a try.
On Sep 10, 11:04 pm, carlos <[email protected]> wrote: > ok only comment is you use > django_evolutionhttp://code.google.com/p/django-evolution/ > > "When you run ./manage.py syncdb, Django will look for any new models that > have been defined, and add a database table to represent those new models. > However, if you make a change to an existing model, ./manage.py syncdb will > not make any changes to the database. This is where *Django Evolution* fits > in." > > 2009/9/10 Thomas <[email protected]> > > > > > Thanks for the advice. I just wanted to ensure I wasn't missing > > something overtly obvious. A bit strange, but I both like, and > > dislike the ORM at the same time. SQL is relatively clean, and > > straightforward... I'd rather abstract more complicated things. I do > > like the idea about adding a column, updating the model and dropping > > the old one. > > > Regardless, I can work with it. I gave up on SQLite3 and re-did my > > settings.py to use postgreSQL as I'm significantly more comfortable > > with that environment. So, things are a bit easier now. I am tempted > > to just import a connection and write straight SQL... which seems very > > easy to do using Django as they keep that option for custom SQL that > > may very well exceed the logical limits of the ORM. I doubt anything > > I'll be writing will get that complex though. So, I'll keep at it. > > Thanks again. > > > On Sep 10, 4:36 pm, Chris Czub <[email protected]> wrote: > > > That is a short-coming of the Django ORM, unfortunately solving the > > > problem of iterative schema changes is pretty difficult. > > > > There are some projects around that attempt to fix this issue, in > > > varying stages of completion: > >http://south.aeracode.org/wiki/Alternativesisa decent list. > > > > As for your specific question of changing the column name - eep :) > > > It's slightly tedious to do that sort of thing seamlessly with the > > > stock ORM. > > > > Here's the workflow I'd suggest for changing a column name: > > > > 1) Manually create a column named after what you want the new name to > > > be, with the same data type, following the Django ORM's naming scheme > > > 2) Copy the data from the old column for all rows into the newly created > > column > > > 3) Update the code and change the property name in the model code > > > 4) Ensure the application seems to be working > > > 5) Drop the old-named column > > > > Note: These instructions may not apply directly, depending on what > > > your property is - in the case of a many-to-many relationship, for > > > example, a join table is used. I'm sure you can figure out how to go > > > from here, though. > > > > -Chris > > > > On Thu, Sep 10, 2009 at 1:31 PM, Thomas <[email protected]> > > wrote: > > > > > I've been teaching myself Django over the past couple of days. Thus > > > > far, everything has been going smoothly, as I typically do a lot of > > > > non-web based Python coding, so am familiar with the language. > > > > However, Django's DB API is my first look into ORM and how it works. > > > > > I understand the basics; how to create models and run a syncdb to > > > > generate tables. I understand how to query, update/insert, etc. the > > > > data by instantiating the class model and using the API methods > > > > against it. All nice and well. > > > > > Where I get lost fast is when I need to make changes to a table. For > > > > example, say I want to change the name of a column from 'foo' to > > > > 'bar'. I can run an ALTER TABLE in SQL and do this easily, but I > > > > thought the idea of ORM was that you weren't supposed to be using SQL > > > > directly. I.e. is there a way to change a column name (or a table > > > > name, or a attribute type, etc.) from within ORM, i.e. from within the > > > > model class; or do I have to run the SQL, then change the model to > > > > 'match' that SQL, and then run a syncdb. > > > > > I love the concept of being able to access data through objects, but > > > > am just confused as what 'workflow' I should be following when doing > > > > something like changing a column name. > > > > > Sorry for the basic question. Google hasn't been much help when > > > > getting into these details. I can sort of 'figure it out' by running > > > > the SQL, matching the model class and going from there... but wasn't > > > > sure if that was the best, or only way. > > > > > Thanks, > > > > Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
