Lee McFadden wrote:
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'd rather write a bit of boilerplate code that I understand, than have to dig through mounds of poor or non-existent documentation to find out how to do something (or more commonly, how to get around the fact that I can't do something). The problem with so-called 'edge' cases is that pretty much every single person has at least one. And when you hit it, if there's no obvious way of fixing it, then the boring old boilerplate code is best. There's no point layering on the abstraction if you lose functionality as a result.
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.
How about I reword it as, "of what little documentation Turbogears has, much of it is or appears to be SQLObject specific"? I will look into SQLAlchemy though.
> 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.
Or... just leave it in the database. Magic! I wasn't referring to two totally separate environments, just the notion that the data should persist through development and release (which, except in some waterfall-methodologist's fantasy world, is often the same thing). It's added by myself and beta-testers via the web front end, just as real data would be, not via code. Data is all-important. I should never have to clear a single thing out of any database just to make a small change to a model, or when I want to remove the "beta" flag from my product and call it a release version. I can certainly appreciate that it's hard to get all the possibly migration cases from one model.py to another right. But why should Turbogears choke just because I added a line like "newCol = IntCol()" in there?
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.
It's not necessarily about project planning, though arguably the main allure of Python comes from rapid, prototyped development, instead of reams of UML and entity-relationship diagrams done in advance. You often want to be able to incrementally grow your model as you develop and the tools should facilitate that. And even if you did have everything planned out in advance, requirements change and live systems have to adapt. Database schemas change all the time and small changes are trivial to do under normal development circumstances. One example is an extra table I had to insert in a PHP project earlier this year. This consisted of creating the table, searching for joins where it would be used, and adding the relevant extra inner join to each one. Done in about 30 minutes. Not a single problem. In Turbogears/SQLObject? Well, I have to add the table in the model, as well as explicitly note backwards references. But that won't propagate down to the database, so I have to add the table there too, and hope that the declarations map across properly, including any magic name mangling SQLObject is doing behind the scenes. Or I can drop the whole lot and re-add it, having had to write and execute both export and import scripts, which is a large waste of time when 99.9% of the data is going right back in exactly the same tables, unchanged. Then I still have to go through my code and search for all the special cases I had to write because SQLObject's 'complex' queries are crippled by design. (And since when was "SELECT LibraryUser INNER JOIN Loan INNER JOIN Book WHERE Loan.expiry > Now" complex, anyway? Seems that way with SQLObject, unless you want the query to run in quadratic time, that is. See how well that goes down with your local librarian...) That's significantly more work than the straight SQL approach I used in PHP. Is this really progress? -- 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 -~----------~----~----~----~------~----~------~--~---
