On Jun 18, 2011, at 4:32 PM, Eric Ongerth wrote: > Just curious and learning here -- There are two separate issues here, > aren't there? (1.) Atomicity of the transaction, taken care of by the > above discussion, and (2.) what if there was a need to have it be not > only atomic but consume as little time as possible between the read > and write, let's say for financial purposes?
Right, so the "executing two statements at once instead of two statements" thing in this kind of case is a fleeting optimization. That is, its a micro optimization that is easily nullified by the surrounding context. Such as, if the way the app works in reality is that the row already exists 95% of the time, the optimization saves negligible time. Or if it's trivial to just pre-insert the rows in question, or a whole selection of 100 rows can be selected at once and just the ones that aren't present can be INSERTed in one multi-row statement, would provide even better performance. Taking a SELECT then an INSERT and making the choice to turn it into a non-ORM, single statement, database-specific call is something you'd do once the app is up and running, and the separate SELECT/INSERT pair has been observed to be a definite bottleneck with no feasible workaround. I.e. a non-premature optimization. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
