does not work when environment was started with empty database

[grosser]

When an rails app is started with eager_load but not database, then attr_encrypted initializes with attr_accessors ... which is bad ... basically trying to be too smart ... maybe it should ask for what kind of setup you want and then verify/blow up when that does not match your columns ... see #212

In my test I now do this to make it behave normally ... seems kind of bad :D

    # hack to make attr_encrypted always behave the same even when loaded without a database being
    # present ... `CI=1 RAILS_ENV=test rake db:drop db:create default`
    # since on load it checks if the column exists and then defined attr_accessors if they do not
    # 
    if ENV['CI'] && SecretStorage::DbBackend::Secret.instance_methods.include?(:encrypted_value_iv)
      [:encrypted_value_iv, :encrypted_value_iv=, :encrypted_value, :encrypted_value=].each do |m|
        SecretStorage::DbBackend::Secret.send(:undef_method, m)
      end
    end

see zendesk/samson#1176

/fyi @saghaulor

[lihanli]

i ran into the same issue when starting with an empty database and loading the schema with ActiveRecord::Migration.maintain_test_schema!, encrypted fields wouldn't save to the db

[grosser]

found a better hack ...

    # A hack to make attr_encrypted always behave the same even when loaded without a database being present.
    # On load it checks if the column exists and then defined attr_accessors if they do not.
    # Reproduce with:
    # CI=1 RAILS_ENV=test TEST=test/some_test.rb rake db:drop db:create default
    #
    # https://github.com/attr-encrypted/attr_encrypted/issues/226
    def attr_encrypted(column, *)
      super
      bad = [
        :"encrypted_#{column}_iv",
        :"encrypted_#{column}_iv=",
        :"encrypted_#{column}",
        :"encrypted_#{column}="
      ]
      (instance_methods & bad).each { |m| undef_method m }
    end

[grosser]

FYI hacky migration to make this work when moving data from an unencrypted column to an encrypted column.

grosser/orgdeps@702b89c

[ryansch]

I ran into this with rake db:reset and was able to fix it by splitting out the seed command like so:

rake db:schema:load_if_ruby db:structure:load_if_sql
rake environment db:seed

[saghaulor]

I believe that #294 should fix this. Can someone please confirm?

[oehlschl]

Just found this thread after some long hours debugging unrelated changes to our CI tooling that triggered a similar case; attr_encrypted properties were written to the models but not persisted to the DB.

Upgrading from 3.0.3 to 3.1 resolved the issue for me. Thanks!

[adelatuduce]

Same as @oehlschl
Thank you for the information. I almost went mad trying to understand why my specs were failing on Circle CI, but when logging into the instance, all of them passed.