I like the sneaky way. I put the basic mechanism in place but I am not sure yet how to implement a useful and practical set of defaults (I am referring to stuff which is totally particular to our organization and not anything to do with SA).
very cool. pjjH On Aug 12, 9:30 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > the most APIish way to do that would be using merge(). > > the sneaky way would be to tap into the "connection_callable" argument > that the sharded session uses. you'd have to read the source to > shard.py to see what thats about. > > On Aug 12, 2009, at 7:13 PM, phrrn...@googlemail.com wrote: > > > > > One of the very nice things about using SQLAlchemy is that since so > > much of the grunt-work is taken care of for you, it gives you the > > opportunity to come up with (potentially) hare-brained schemes like > > the one I just thought of. We would like to do reading of data with > > one set of logins and do writing with another. The reader 'binds' are > > pretty straightforward but the writer binds vary quite a bit from > > database to database and platform to platform (we have integrated > > security on some OS/dataserver/drivers/languages) The idea I have is > > to maintain a writer session with the specialized engine bindings and > > have the reader session copy any dirty data over to it at commit/ > > flush time (I got the idea from the thread on this group entitled > > "Updating database after after_insert()"). Is this a total kludge? Has > > anyone tried to do something like this already? > > > thanks very much. > > > pjjH --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
