> Here's a point that hasn't been made yet: you can pretty much skip all the ORM > features of SQLAlchemy and just issue plain old SQL statements directly to the > engine. That's one of the reasons why I used and still use TG. Personally I > hate ORMs as for me - someone who can actually write SQL with no intention > to > switch databases - it's overly complicated to form a 10 line pretty much > unreadable statement in python that's just one line in SQL. But that may just > be me. > The upside on using the ORM sure is the mapping which makes is very simple to > access the data. Complicated joins however are a PITA with an ORM, so I use > views and procedures for those, just to map them via the ORM in a simple > "select whatever from (view, procedure) where (restriction)". Whenever I need > to change the logic I don't even touch the python code - I just change the > view or procedure and best of all I can do it while in production and the next > request will get the new version. That really suits my insurance customers.
Uwe, What about updates to the data? How do you handle that. That is where an orm starts to pay off imho. I'd be curious to know what you do. Do you use updateable views/procs? Other than that, I agree that direct sql can be the way to go if that is what you are used to. -- 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.
