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 -~----------~----~----~----~------~----~------~--~---
