On 12/26/06, Ben Sizer <[EMAIL PROTECTED]> wrote: --8<-- snip --8<--
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.
I strongly disagree here. Even SQLObject (which, for me and many others, has fallen by the wayside in favour of SQLAlchemy) saves many many lines of boilerplate code and, although it may be a bit of a beast to do complex queries with, still saves you time and effort. I just don't see how you would benefit from using straight dbapi calls in all but the most complex of edge cases. I would suggest you take a look at SQLAlchemy. There are links to a number of tutorials about using SA with TG on the docs site[1] and the SA docs themselves[2] are superb. There is also migrate[3] (and possibly tgmigrate[4] depending on how well it works - i've not used it personally) which would seem to cover what you want with regards to updating your schema when your model changes. With regards to "half of turbogears is wed to this awkward piece of kit" - The only part of TurboGears that is included with the current distribution that *requires* SO is catwalk, IIRC. Any other component doesn't care how it gets its data, that's up to you. So if you really did want to write your own dbapi model there would be nothing stopping you. [1]: http://docs.turbogears.org/1.0/ [2]: http://www.sqlalchemy.org/docs/ [3]: http://erosson.com/migrate/trac/ [4]: http://cheeseshop.python.org/pypi/tgmigrate/0.2 --8<-- snip --8<--
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.
Again, I'm afraid I'm going to have to disagree with you here as you seem to be contradicting yourself. You say you don't want to have to define the test data in Python, but then you say that you would like to have some of your data carried across to the production environment. There are only really two ways of doing that automatically: Create the data using a Python script to "bootstrap" your application or have the data defined in an SQL script to do the same thing. I know which *I'd* rather write. TurboGears doesn't make this hard, you're expecting TurboGears to do some magic and help you with your project planning. If you think/know that your schema is going to change between versions you should be prepared to put the extra work in and make sure that your schema gets modified accordingly. Version your database. Make sure you track all of your schema changes. Make sure that you know if there will be differences in columns between different RDBMS's and platforms. I know that when updating/upgrading the schemas in my apps I'm very careful about all the above and it's not *that* hard to make sure that you don't axe all your data or your app. I hope this helps. Lee -- Lee McFadden blog: http://www.splee.co.uk work: http://fireflisystems.com skype: fireflisystems --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
