version 1.0.3 of after_commit causes problems

[joshuacronemeyer]

The 1.0.3 gem of aftercommit causes the following error when i run
migrations:
undefined method `unique_transaction_key' for
#<ActiveRecord::ConnectionAdapters::PostgreSQLAdapter:0xb714c1f4>

I am on the 1.3.4 gem of thinking sphinx

It looks like the after_commit connection_adapters.rb isn't mixing in
properly so the unique_transaction_key method which gets called from
the active record models hasn't been added to the connection adapter.
I don't know why and I don't know if this is an after_commit problem
or thinking-sphinx problem. In any case, I thought it was worth
mentioning.

My current workaround was to revert to the 1.0.2 gem of after_commit.

[Pat Allan]

Hi Joshua

Thanks for pointing this issue out - I've had a few others contact me
about the same thing, and will hopefully have a new version of
after_commit published sometime in the next 24 hours that fixes this
bug.

Cheers

--
Pat

> --
>
> You received this message because you are subscribed to the Google
> Groups "Thinking Sphinx" group.
> To post to this group, send email to thinkin...@googlegroups.com.
> To unsubscribe from this group, send email to thinking-sphi...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en
> .
>
>

[Mark Goris]

Hi Pat,

Based on the backtrace from the error I'm seeing with after_commit >
1.2, I suspect the same root cause is at play here. However, it seems
worth posting just in case anyone else is struggling with this.

I'm seeing an error when running specs for my application, with the
following backtrace (and error message):

mark@marklx:~/source/aspen$ spec spec/models/sender/
sender_type_spec.rb -b
F.....

1)
NoMethodError in 'SenderType validation should create a new type with
valid options'
You have a nil object when you didn't expect
it!
You might have expected an instance of
Array.
The error occurred while evaluating nil.
+
/usr/lib/ruby/gems/1.8/gems/after_commit-1.0.4/lib/after_commit/
connection_adapters.rb:157:in `increment_transaction_pointer'
/usr/lib/ruby/gems/1.8/gems/after_commit-1.0.4/lib/after_commit/
connection_adapters.rb:11:in `commit_db_transaction'

The interesting thing is that after the first example in the spec, all
the other examples pass. This can be repeated across multiple specs;
first example in the first spec fails, everything else passes.

Mark

[Pat Allan]

Hi Mark

I've not seen this problem yet - can you confirm it happens with the
latest version of after_commit (1.0.4)?

--
Pat

[Mark Goris]

Hi Pat,

Yes, version 1.0.4 is where I first ran into it, and happened in 1.0.3
as well. Moving back to 1.0.2 fixed it, but then I had the infinite
loop problem, which is even worse.

So something between 1.0.2 and 1.0.4 caused this. Given the way it is
manifesting (first example in a spec, then everything else if fine),
it sure seems like a bootstrapping problem, which is why I stumbled on
this thread when trying to find an answer.

Mark

[Pat Allan]

Hi Mark

I've just pushed 1.0.5, which will hopefully fix this problem - if you
could test it and confirm, that'd be great.

Cheers

--
Pat

[Mark Goris]

Tested, and 1.0.5 looks to have fixed the problem. No issues with
running specs. Note that I didn't execute any migrations, as the OP
had trouble with.

Thanks for the help.

Mark