Great answer! I no longer misunderstand :) It looks like 'transaction_status' gives us what we want: https://github.com/ged/ruby-pg/blob/219f33223b7fa9f3d352e993ccb0eaa598a05e1a/ext/pg_connection.c#L720 <https://github.com/ged/ruby-pg/blob/219f33223b7fa9f3d352e993ccb0eaa598a05e1a/ext/pg_connection.c#L720>
If it's PQTRANS_IDLE (0) we probably don't want to ROLLBACK. If it's PQTRANS_INERROR (3) (or anything else?) we probably do. It appears to be available in the pure-Ruby version as well: https://github.com/mneumann/postgres-pr/blob/master/lib/postgres-pr/connection.rb#L36 <https://github.com/mneumann/postgres-pr/blob/master/lib/postgres-pr/connection.rb#L36> > On Jun 18, 2017, at 17:30 PM, Jeremy Evans <[email protected]> wrote: > > On Sunday, June 18, 2017 at 4:42:10 PM UTC-7, Daniel Leavitt wrote: > See testcase here: > https://gist.github.com/dleavitt/0f413129f9fbefe681f9d49e8b86bad6#file-testcase-rb > > <https://gist.github.com/dleavitt/0f413129f9fbefe681f9d49e8b86bad6#file-testcase-rb> > > When a Sequel transaction fails due to a deferred constraint violation, it > calls "COMMIT" anyway, which leads to a PG warning: "WARNING: there is no > transaction in progress" > > You are misunderstanding what is happening. You appear to think the flow is: > > BEGIN -> INSERT (Error) -> COMMIT > > What actually happens for a deferred constraint violation: > > BEGIN -> INSERT -> COMMIT (Error) -> ROLLBACK > > The "no transaction in progress" warning comes from the ROLLBACK statement, > just to make sure the transaction is rolled back, as I'm not sure that a > client-side error during commit in all cases will roll back the transaction > server side (it will in most cases, but possibly not all). > > Seems like a bug but not sure if it's readily fixable? Is Sequel able to > check if the transaction was already rolled back? > > It may be possible to use driver-specific methods to check connection state. > As long as the code works for both work for pg and postgres-pr drivers, I'd > consider it in the postgres adapter. > > It also got me wondering why Sequel defaults to wrapping "save" and friends > in explicit transactions - I know most ORMs do this but wasn't sure why. What > would I be losing if I set "use_transactions" to false on Sequel::Model? > > You'd lose atomic behavior. If you have any other queries in save hooks, > this could be problematic. If not and the database supports returning (so > the insert+primary key select is a single query), it's probably OK to > disable. Using transactions is the safe approach, but Sequel does offer ways > to turn the behavior off if you want to. > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to a topic in the Google > Groups "sequel-talk" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sequel-talk/2SsDLKQcKko/unsubscribe > <https://groups.google.com/d/topic/sequel-talk/2SsDLKQcKko/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/sequel-talk > <https://groups.google.com/group/sequel-talk>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
