relation "some_table_name" does not exist at character 13

[ramontayag]

I have not gotten to the heart of the matter, but I get this error when running a spec. However, this spec only fails when one before it that uses the same schema is created.

• Rails 3.2.3

   ActiveRecord::StatementInvalid: PG::Error: ERROR:  relation "asset_groups" does not exist at character 13
: INSERT INTO "asset_groups" ("created_at", "name", "updated_at") VALUES ($1, $2, $3) RETURNING "id"
from /Users/ramon/.rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.2.3/lib/active_record/connection_adapters/postgresql_adapter.rb:1152:in `get_last_result'

For documentation's sake, here are some guesses as to why this happens:

• Cached statement does not properly take into account search_path. Because the 2nd spec just truncates the schema, and runs the test on that schema, then perhaps there's some funkiness. This is a wild idea though. I looked at the Rails 3.2.3 code and poked around but did not get far.
• The schema truncation within a transaction does some funky stuff to the state of the db.

[ramontayag]

In my suite I fixed it by just creating a different schema, instead of switching to the existing one and truncating it. Perhaps I should try to truncate the schema outside of a transaction. Better yet, do all of the schema creation/truncation outside of a transaction. An idea:

Tenant.create_with_schema #creates tenant, then creates schema

instead of a before_create callback that does it in one transaction.

[ramontayag]

I've been able to avoid this issue altogether this in my app by not creating/truncating in a transaction. I had previous used a callback on a model to create a schema:

class Tenent < ActiveRecord::Base
  before_create :create_schema

  def create_schema
    Storey.create self.schema
  end
end

In my tests, to speed things up (since creating schemas are not fast), I monkey-patched create_schema to truncate it if it existed instead. This is where I ended up seeing these issues. Since callbacks are falling out of favor anyway, I did away with it completely and call a method like tentant.create_schema_and_save that creates a schema if the model is valid and then saves it. I still kept the monkey-patch in TEST mode to truncate the schema if it exists, but that's a non issue now that create_schema is called outside of a transaction.

I will close this as I've decided this isn't an issue with Storey, but with the nature of transactions and PostgreSQL. The hint to the developer should be sufficient and lead them to this issue.

[ramontayag]

This started happening again in the Storey tests themselves - in the duplication specs. It seems to happen when running two specs in order. I found out that reset_column_information on the model fixes the problem. Perhaps the issue is that the cached information about the schema that was just duplicated has wrong information about the tables. Which is why clearing it works. Perhaps resetting all the models after a switch helps? Will this waste a lot of time? If it's only a few milliseconds, it might be worth it.

Here's how we can get all descendants of ActiveRecord::Base: http://stackoverflow.com/questions/2393697/look-up-all-descendants-of-a-class-in-ruby

[ramontayag]

Here's another entry for this weird issue - it went away after I stopped resetting. It seems that the reset fixed it the other day, but why does it work now? Will keep it open until I find a solution.