[sqlalchemy] Re: session.flush calls commit, and Binary issue
flush() starts its own transaction and commits it. if you have already opened a transaction on the current session, then it will nest inside the larger transaction. see the SessionTransaction documentation for details. Also, the pickle type not getting updated is something that was fixed in the 0.3 series, and we have unit tests that insure a non-changed pickle type does not trigger an update. I need a fully functioning test script showing me your schemas for this one. (using PickleType, correct?) additionally, if you call a flush() inside a larger transaction, and the flush fails, its going to roll the transaction back. not sure what functionality youre looking for , a flush that commits part of the way, screws up, and doesnt roll back the invalid data , so that you can commit it all ? are you sure you arent looking for a separate transaction to commit the data that must be committed ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: session.flush calls commit, and Binary issue
I am using PickleType, and Binary on the same table.. I'll see if I can come up with a small test. These fields are being written back every time any other field changes, even when they haven't changed. Regarding transactions. I thought session.flush was just UOW work and didn't actually do commits. I need a outside transaction wrapper that begins when a web request is received, and commits if the web request was processed w/o error. In that use case, session.flush should not actually commit it's changes. My second use case (described in the original message) is that occassionaly, within this transaction wrapper, I will need to make a commit once in a while. So write me up as really confused now.. I thought session was just UOW and didn't handle low-level transactions at all.. I am using explicit connections and sessions.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: session.flush calls commit, and Binary issue
let me tell you how pickletype works right now (by default, you can change it). there is a method on all TypeEngine objects called compare_values(). this method is now used by the attributes package when it checks if something changed. in most cases, the method uses a the == comparison. In the case of PickleType, by default it does something different: def compare_values(self, x, y): return self.pickler.dumps(x, self.protocol) == self.pickler.dumps(y, self.protocol) why does it do that ? because it is exhaustively detecting any change anyhwere within the pickled state. I would hypothesize that something is changing somewhere in your binary data. To turn the feature off, use the flag mutable=False when you declare your PickleType. Then it will use the old method, using the is operator (i.e. x is y). you can also subclass PickleType and add a comparison of some other method, i.e. using == for example. for your transaction issue, its important to understand the automatic nesting of transactions in sqlalchemy. if you begin a transaction on a resource, and then someone else also begins an transaction on the same resource, you control the transaction; the inner call gets a placeholder transactional object which is capable of rolling back the transaction, but not committing it. to commit the transaction, the original outermost caller that began it must commit. in the case of UOW, it begins its own transaction, and commits. this is essential for the flush() method to work properly, since it a). is issueing many SQL statements which must be in a transaction (therefore begin()) and b). has to have the data written to the DB when its done (therefore commit()). If you are using your own transaction on the same resource, then the UOW's transaction will nest into yours as described above. The transaction nesting can be used via the SessionTransaction interface or also through the Transaction object off of Connection. connection = e.connect() transaction = connection.begin() session = create_session(bind_to=connection) ... do stuff.. session.flush() transaction.commit() its all in the docs in the Sessions chapter. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
