On 6/27/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > 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.
That's a good idea. I also will increasingly need to access my web applications' data from command-line tools, such as usage-report generators and quasi-static webpages. > > 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.) It sounds a bit abstract for me to work on, but let me know if it will require changes to SAContext. I envision SAContext can be a "plugin" to this system. I also use Durus so I'd like to get it working with pylons.templating autoconfiguration at some point. I have an idea even crazier than yours: a SQLAlchemy engine for Durus, which may support only some SQLAlchemy features but would at least explore the possibility of managing a SQL and non-SQL database from a common front end, for possible use in interoperability or database-copying scenarios. But it's still just an idea. > 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. I hadn't heard of DejaVu until now. One issue with SQLAlchemy is connect/rollback are buried in the SQL and ORM APIs, so I'm not sure how useful it would be to shoehorn them into this API which is "out of band" from the controller code. Is this a full-request transaction the controller is expected to use? Can we assume that every controller has no more than one transaction, and that rollback always corresponds to certain HTTP status codes? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
