> It's proven trivial to drop SAContext into > an existing Pylons application (one variable definition and two > search-and-replaces) so I expect the same will be true for TG > applications.
Yea, Jonathan has stuff to talk to you about. I think SAContext could be pretty easily modified to meet his needs. (He wants to share models between Pylons and other command line tools), but I think that's a use case we should try to address if we can. > I'm not sure whether the module will be called > pylons.database or pylons.database.sqlalchemy or something like that, > but that'll be just a matter of changing imports. I had this crazy idea this morning when talking to Jonathan. The idea would be to create a more generic database interface go in (perhaps on top of SA Context.) I'd like there to be an entry point for database "engines" (SA, SO, DejaVu, or whatever) that offer a very minimal set of functions in a database agnostic way. * connect * start_transaction * end_transaction * rollback This would make it possible for Evelind or others to write a DejaVu engine for Pylons/TG that just works when installed. Actual database manipulations would happen in application code in whatever way users want and would not touch any of these functions. But we can call connect to initalize the engine, and we can call the other methods from a new generic "transaction middleware" component that we need to write for TG on pylons. But Jonathan has more details on the actual use case for this than I do. So, hopefully he'll chime in on this too. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
