DarkBlue ha scritto: > Please do not forget to post any findings here. > > While SO/SA has it's advantages , if you want > to graft an existing database into the SO/SA > model for use with TG you will run into endless > problems with triggers and generators. >
How so? I am happily using sqlalchemy, and a bunch of features of the ORM, while keeping the schema, DDL, stored procedures and triggers firmly in SQL where I feel they belong. I have triggers to enforce sequential (time based) constraints, keep audits of modified data, and create event tables for other applications to process. I understand the efforts to develop the best ORM in the python world, but the single feature I appreciate most is the autoload. It shows due respect for the DBMS side, and that's unusual in this decade full of "type this and be amazed" :-) If there are shortcomings in my approach (except having to do funny things to run tests, which I did (*)) I cannot see any, but I may be wrong. (*) i.e., upgrading to sqlalchemy 0.3.7 completely breaks my functional tests, though the real application works the same. Something to do with the visit handling, not with triggers or anything like that. I suppose a bug in my DBTest class, I'll look into that. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
