Better recovery from failed flush

[Matt Haggard]

I've added a tests to a patch by marienz.

I don't know how bzr works yes, but here's the branch: https://code.launchpad.net/~magmatt/storm/recover-from-failed-flush

[James Henstridge (jamesh)]

What kind of flush failures are you trying to recover from?

[Matt Haggard (iffy)]

If you violate a database-enforced unique key. Here's the test case:

http://bazaar.launchpad.net/~magmatt/storm/recover-from-failed-flush/revision/377

And here's a short example of how to do it: http://paste.pocoo.org/show/277464/

[Matt Haggard (iffy)]

Oh, and the reason the end result in http://paste.pocoo.org/show/277464/ is bad is because f2 does not have an id.

[James Henstridge (jamesh)]

Sorry for not getting back to you on this. If you receive an IntegrityError from the database, your only recourse is to roll back the transaction and try again. For instance, with PostgreSQL I get:

  template1=# create temporary table foo (id serial primary key, bar text unique);
  CREATE TABLE
  template1=# begin;
  BEGIN
  template1=# insert into foo (bar) values ('whatever');
  INSERT 0 1
  template1=# insert into foo (bar) values ('whatever');
  ERROR: duplicate key value violates unique constraint "foo_bar_key"
  template1=# insert into foo (bar) values ('something else');
  ERROR: current transaction is aborted, commands ignored until end of transaction block
  template1=# commit;
  ROLLBACK

The face that sqlite is letting you commit after this error sounds like a bug. it isn't a mode of use we are trying to support.