Thanks for taking the time to respond. If I'm understanding what you're both saying then the best approach may be to abandon using my customized db wrapper and go back to using standard sqlalchemy. Since i have not really started the reporting app yet, that's certainly doable. One of the reasons I was opting for the custom solution was that it would give me a separate place to put all the packaging of the data to be returned to the web app. I'm dealing with complex data where I will normally need to touch 5 to 8 tables to put all the pieces needed together in a query. My db structure is granular. Instead of using things like Oracle stored procs and/or complex views, which would anchor me in future to Oracle, I want to keep that logic in the application, outside the database. I originally wrote the db load application using sqlite on a Windows machine and then ported it to Oracle on Linux, simply by re-writing the db wrapper. I'd like to continue in that vein so that, should the company decide to move to another DB in the future, it won't be an issue for my application. So now, assuming I go with pure sqlAlchemy, is there a way I can deploy a python class between my web app's view callables and the database to house the functionality I was going to put in my custom wrapper? As I said before, at this point I'm simply trying to decide the route to take, not the actual detailed specifics of the solution. One other thing occurs to me:- Since Pyramid has all this routing infrastructure built in, would another solution possibly be to build a separate app which would service database requests and create a layer (where I could put my custom data packaging)? My reporting app could then route db requests using urls to this separate database servicing app?
I'm sorry if this is not 100% clear. I'm trying to ensure I have a layer in my design where business logic is implemented with as little technical clutter as possible. On Tuesday, July 12, 2016 at 11:37:21 AM UTC-4, Jonathan Vanasco wrote: > > > On Tuesday, July 12, 2016 at 1:11:30 AM UTC-4, Mike Orr wrote: > > 8. If you don't want to use the ORM, you can make a request property >> that returns an engine or connection (#2, #3, #4, #5). I don't know >> whether you could register that with Pyramid's transaction manager; >> you'd probably have to use a 'zope.sqlalchemy' class or write your own >> adapter. But you don't have to use the transaction manager. >> > > as a variation on this... If you setup the ORM you can work directly with > the dbSession's connection (using core, the underlying cursor, etc), and > all that work will happen within the pyramid_tm transaction > > however, sqlalchemy won't know that you did anything since you bypassed > it. you need to import `mark_changed` from zope.sqlalchemy and then do > `mark_changed(dbSession)`. otherwise the default rollback will issue > instead of a commit. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/24a9bf2e-b228-4864-a147-958808b9807b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
