Diez B. Roggisch wrote:
Ben Sizer schrieb: > > 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. 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.
Surely this covers a good 90% of the cases. It would be better than nothing.
The only question arises if this is better done in Python - working with the model itself somehow - or in SQL.
Another question arises - why on earth do we wedge something like SQLObject into this framework if you then need to write external SQL scripts just to do the simplest and most obvious of things? If necessary, I can add the line to the model, then use ALTER TABLE ADD COLUMN in MySQL, and hope for the best. Is there any way I can get some more reassurance than just "hoping for the best"? If there was at least some sort of 'model consistency checker' I could run that and catch my error early on.
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.
It's rapidly getting to the stage where I think I would be much, much, much more productive just using the DBAPI directly rather than jumping through all these ludicrous ORM hoops. Sure, columns as attributes is nice and simple, but surely any non-toy application is going to have some complex queries, and occasionally changes to the data model. I already had someone on the SQLObject list suggest yesterday that I am somehow asking too much, hoping that a simple query containing 2 INNER JOINS - the very backbone of relational data - might not require explicit looping over thousands of queries using SQLObject. It's a joke. Unfortunately it looks like half of Turbogears is wed to this awkward piece of kit.
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.
I don't want to have to define test data in Python. I have lots of it, added in via the website's usual mechanisms, which I would like to persist when I do something trivial like add an extra column. Some of it, I'd like to carry across to the released version in the end (which will surely also have some database changes in its lifetime). Turbogears makes this hard. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
