Well, I can't argue with working code. I guess that means I was doing something wrong. Now if only I could figure out what (two year old project, not likely to dig through it now, honestly).
Thank you for showing this to me, Diez. Means I can get rid of some of the redundant crap I've been thinking I need to do. On Wed, Apr 27, 2011 at 9:16 AM, Diez B. Roggisch <[email protected]> wrote: > On Wednesday, April 27, 2011 02:31:12 pm Michael Pedersen wrote: > > On Wed, Apr 27, 2011 at 5:11 AM, Diez B. Roggisch <[email protected]> wrote: > > > On Wednesday, April 27, 2011 04:50:46 am Michael Pedersen wrote: > > > > Going by my own experiences, I think it's just a case of your being > > > > lucky in your development environment. Quite likely, the timing of > the > > > > redirect coming to the browser is just long enough for the data to be > > > > saved to disk, and the subsequent request from the browser is able to > > > > be > > > > > > satisfied. > > > > > > That makes no sense. There is no concurrency involved here. Whatever > the > > > first > > > request does, when the page is returned to the browser, the transaction > > > is committed (or rolled back of course), and the data is in the DB. > > > There is no > > > chance for it to appear later somehow. > > > > I have seen the behavior I described occur. It may not make sense, but it > > happens. For whatever reasons, the redirect results in a case where the > > browser is capable of sending a request for the newly made data before > the > > data is committed to disk, and the result is an inability for the browser > > to get the data. > > > > One way it could make sense: redirect is implemented by way of an > > exception, if memory serves. Exceptions result in the normal flow > > departing, which would result in the browser getting the redirect before > > the commit is done by TG. I haven't looked at the code to verify that is > > what happens, but that is a real possibility. > > Nope, that's not what is happening. You are right that the redirect is done > using exceptions, but it's not percolating beyond the transaction > middleware. > > I'm sorry, but I'm very, very sceptical that the behavior you think you > observed is the one that's really occuring. If it was, it's a huge bug, and > I > guess it would have been found already. But nothing is impossible, of > course. > > On thing that has bitten me was the lack of a flush, so that the ID I got > was a > None instead of an actual ID. And that of course made my redirect go > wrong. > > > > And DBSession.flush() is the right thing to do, if you want all > > > outstanding SQL > > > to go to the DB, and thus getting your entities some nice & fresh IDs. > > > Commit > > > isn't needed for that. > > > > Again, I have seen that behavior required, particularly if you are using > a > > transaction aware database. Since each transaction is executed in > > isolation, and therefore not visible outside the transaction, until the > > actual commit(), no subsequent request will be able to see those IDs. > > While this won't affect (for instance) MySQL, it can affect SQLite, > > PostgreSQL, and others. > > This is not entirely right, as it depends on your transaction isolation > level. > It might well be that you can see changes in one transaction that occured > in a > different one. See here for what postgres does there: > > http://www.postgresql.org/docs/8.1/static/transaction-iso.html > > But it's a tangent for this discussion I'd say. See below. > > > > If all you are looking for is the ID numbers, then yes, flush() is > correct. > > If you are looking to make sure that other requests can *see* those ID > > numbers, then yes, commit() is required. > > Yes, that's right. But then again, we are at the concurrency issues: the > request that *created* the row in the table is the same request that > created > the redirect. And that very redirect is then communicated back to the > browser > via a HTTP 302-status-header. > > But this means that it absolutely 100% has gone past the transaction > middleware, and thus is commited. So I don't see how the OP's observed > behavior could be explained by this. > > In general, there should be no need to manage transactions yourself in TG2. > You might *want* to, for whatever reason, but this simple CRUD-behavior > should > just work, and does to the best of my knowledge. > > And I just decided to test that, and created this little test-project, > which > clearly shows that things are working as expected: > > https://bitbucket.org/deets/tg2-tm-test > > HTH, > > Diez > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" 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/turbogears?hl=en. > > -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
