On Jun 9, 2008, at 2:22 PM, qhfgva wrote:
> > Thanks I'll take a look. I left out what I think is an important part > of this scenario (or maybe it's trivial - I don't have a good > perspective on this yet). In any case, I would like to use the ORM > component of sqlalchemy and completely hide the fact that the read/ > write connections are possibly different. (They might become the > same connection if the local database becomes unaccessible and/or is > too far behind the master). that is going to be very hard to accomplish as the Session does not have a clustering rules engine built into it in order to determine read/write locations, nor is that within its scope. It can only handle "class X talks to engine Y". > In other words I'd like to have a handle to, say, a user object, and > do reads/updates to it with the programmer using this object not > caring about how the work gets done. So for instance I select a > number of user objects that come from the local database. Later I > update a field on one of these and the update takes place on the > master directly. > > Is that weird? Doable? Unfortunately this is the environment I need > to get this working with. you need to make a facade on top of Session which accomplishes this, most likely by using multiple sessions. Rebinding a single session mid-stream is somewhat possible as well, but you'd want to ensure that the session is not engaged in a current transaction when this happens. Another, more dramatic approach is to handle the multiple engines as the SQL execution level; look at 0.5 and the ConnectionProxy class. The ConnectionProxy is simple but you'd have to intelligently inspect the statements coming in to determine where they should be routed. Of particular concern would be again transactional state; when a flush() occurs and writes data to the write engine, the flush() still needs to read from that same engine in some cases, such as when deleting collections where it wants to locate the set of primary keys. Similarly, if a read operation detects a certain state that is then not present on the different-engined write operation (or vice versa), that inconsistent state can lead to errors. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
