Infinite validations

[glebm]

If auto_register is on here is what happens:

validate_by_openid calls auto_reg_record.save which calls Authlogic::Session::Cookies::InstanceMethods#persist_by_cookie which calls valid? which calls validate_by_openid, et cetera...

[glebm]

I am using pg, memcached, and rails 2.3.5. Would be nice if you could fix it (I don't know if it is db specific, because on postgresql every call gets wrapped in a transaction, but postgresql is definitely an important database).

I hacked up a temporary solution that seems to work for now (but it is strictly temporary, a better fix would be nice): http://gist.github.com/371884#file_seesion.rb#validate_by_openid

[mreinsch]

Interesting we're not seeing this on MySQL...

[glebm]

What do you think about my solution?
Does it look like it can break something else?

[mreinsch]

Could you fork of and commit your patch? It isn't really easy to read in a gist. Thank you.

[glebm]

Sure: http://github.com/glebm/authlogic_openid/commit/cac94dca5dacadb40220e65505ae02691b152fe6

It is bit dirty, but then again I am not sure if it is the right way to do it.
It does seem to work O.K. though, but maybe I should use something like a thread-local variable instead of a static field... I dunno...

[glebm]

I made it threads-friendly, I think we can merge now :)

[glebm]

The reason for the problems with PostgreSQL is that authlogic_openid relies on the records created inside of transaction being available in it.

I.e.:

transcation do
    Record.exists?(:identifier => "xyzzy") # => false  

    Record.create(:identifier => "xyzzy")

    # not reliable! should not be used
    record = Record.find_by_identifier("xyzzy") 

    puts record 
    # => the record (MySQL/SQLite3)
    # => nil (PostgreSQL/Oracle)
end

My fix is a hack that uses a thread-local variable to track the record.

A definitely better solution would be passing down and getting back the records from various plugged in validations, but I am not experienced enough with authlogic to implement it.

[mreinsch]

Thanks for looking into this.
The behavior you describe sounds strange to me, at least according to http://www.postgresql.org/docs/8.3/static/transaction-iso.html, the select should be able to see any changes made within its' own transaction?

[glebm]

Hmm, I'll recheck then

[glebm]

Oh, I see.
Are there any nested transactions in there?
Because if there are, I'll need to check if you can read the new stuff from within a nested transaction, i.e.:
BEGIN;
UPDATE stuff...;
BEGIN;
SELECT stuff...; -- can you do this in postgresql?
COMMIT;
COMMIT;

In rails nested transactions are implemented with savepoints, so the issue might be there