Closed thomas-mcdonald closed 9 years ago
I'm seeing this behaviour as well. ActiveRecord enums are stored as integers in the DB, but can be referred to with their integer values or string representations in the application. When I try to import the records I created (with varying enum, and therefore integer, values), they are all inserted with 0, instead of the correct value for that record.
hrm. this is not good. would either of you be willing to submit a patch?
I've started to give it a try, but it's a bit more involved than I expected. Keep in mind that I am relatively new to Ruby. However, it seems to me that some changes occurred in the unit testing aspects from 4.0 to 4.1, moving from test-unit to minitest, (I realize I'm possibly speaking partial nonsense, due to lack of experience in this realm).
Basically, I started out just by trying to get a failing test for this feature, but after adding a Gemfile for 4.1 (referencing activerecord 4.1.0), I'm having difficulty getting the test suite to execute (rake test:postgres runs, but no tests execute).
rake test:postgresql
/Users/zkhan/.rbenv/versions/2.0.0-p353/bin/ruby -I"lib" -I"/Users/zkhan/.rbenv/versions/2.0.0- p353/lib/ruby/gems/2.0.0/gems/rake-10.3.2/lib" "/Users/zkhan/.rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/rake-10.3.2/lib/rake/rake_test_loader.rb" "test/adapters/postgresql.rb" "test/import_test.rb" "test/synchronize_test.rb" "test/value_sets_bytes_parser_test.rb" "test/value_sets_records_parser_test.rb" "test/postgresql/import_test.rb"
-- create_table(:schema_info, {:force=>true})
-> 0.0996s
-- create_table(:group, {:force=>true})
-> 0.0142s
-- create_table(:topics, {:force=>true})
-> 0.0076s
-- create_table(:projects, {:force=>true})
-> 0.0096s
-- create_table(:developers, {:force=>true})
-> 0.0085s
-- create_table(:addresses, {:force=>true})
-> 0.0052s
-- create_table(:teams, {:force=>true})
-> 0.0072s
-- create_table(:books, {:force=>true})
-> 0.0086s
-- create_table(:languages, {:force=>true})
-> 0.0045s
-- create_table(:shopping_carts, {:force=>true})
-> 0.0057s
-- create_table(:cart_items, {:force=>true})
-> 0.0133s
-- add_index(:cart_items, [:shopping_cart_id, :book_id], {:unique=>true, :name=>"uk_shopping_cart_books"})
-> 0.0047s
-- create_table(:animals, {:force=>true})
-> 0.0093s
-- add_index(:animals, [:name], {:unique=>true, :name=>"uk_animals"})
-> 0.0033s
-- create_table(:widgets, {:id=>false, :force=>true})
-> 0.0045s
Run options: --seed 30081
# Running:
Finished in 0.056394s, 0.0000 runs/s, 0.0000 assertions/s.
0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
I will keep looking at it, but maybe an expert's insight can save me some debugging hours.
I also started poking around at the source, but I think I ended up bypassing the issue by rewriting the code to use postgresql COPY
.
I can't really look any further for a month or so as I have exams coming up.
I've fixed it since it is overlooked for a bit long time.
I have added another way to fix the enum problem which seems a bit simpler (and hopefully merge worthy).
That fix works for me - thanks!
This is a must have
:+1: Bump
I'm all for this, we need an associated test though, not just the implementation. If someone can update #164 with a test, this will get pulled in much faster.
+1, we wasted half a day until googling to find there's an issue with enums. Makes this gem un-useable
+1 Made a lot of changes on my code to use this, and then this bug...
please fix this.
@arashm deserves all the credit for fixing this. A 0.10.0 gem has been pushed to ruby gems incorporating his fix.
From experimenting with my importer today it appears that enum fields are being inserted as
0
regardless of the string/integer value assigned to them.