ageweke / low_card_tables Goto Github PK

Hi @ageweke, this is a pretty interesting idea! I'm implementing it on a new project and I'm wondering if there's any gotcha for using it along with factory_girl

Seems like it doesn't recognize factories using low_card_table attributes, not even within the has_low_card_table model.

Any thoughts? Thanks!

I'd love to use this gem in my latest project, but unfortunately I'm using JRuby and Postgres, which is non-compatible according the README (and my test suite).

As mentioned in the readme, this gem is dependent upon activerecord-import, which seems dubious given the point of the low card system is that you're only dealing with small-ish number of permutations.

Would you be open to accepting a PR that removes this dependency? I may be able to find some time this weekend to bang it out.

Thanks,
Scott

P.S. I hope everything is going well with you AG :)

It looks like predicate methods aren't proxied, for example:

user.active #=> true
user.active? #=> NoMethodError: undefined method `active?' for #<User:0x007fde89526088>
user.status.active? #=> true

Hi

I'm trying to use this gem but am getting an error when I run rake db:migrate. I am adding the foreign key to the parent table in the migration like so:

class AddLowCardTableToEvents < ActiveRecord::Migration
  def change
    add_column :events, :event_attribute_id, :integer, null: false
  end

  create_table :event_attributes, :low_card => true do |t|
    t.boolean :bypass_meeting_requirement, :null => false
 end
end

I've update the parent model like this:

class Event < ActiveRecord::Base
  has_low_card_table :attribute
  ...
end

And defined the event attribute model:

class EventAttribute < ActiveRecord::Base
  is_low_card_table
end

When I run the migrate task it complains:
You said that Event has_low_card_table :attribute, and we
have a foreign-key column name of "event_attribute_id", but Event doesn't seem
to have a column named that at all. Did you misspell it? Or perhaps something else is wrong?

I -think- this is because the migration loads the Event model which in turn does the pre-check to ensure the key is present, but it's not, so it bombs out. If I comment out the is_low_card_table line in the model it works, and I can then uncomment it fine, but this won't work if I commit the code as other users will have the same issue.

Great looking gem by the way, thanks :)

Hey @ageweke , it's been a while, how's it going?

We just started using this gem, because it was so helpful before ;)

However, we just stumbled on an issue with table locks.

We're using the DatabaseCleaner gem with Rspec, to cleanup the database around our specs. It has several strategies, and one of them is transaction, which uses savepoints to rollback queries.
https://dev.mysql.com/doc/refman/5.5/en/savepoint.html

It was working great until we added low_card_tables. Since it does a LOCK .. WRITE; ...; UNLOCK TABLES; when adding new rows, UNLOCK creates an implicit transaction COMMIT, so savepoints get released automatically. So the next time the DatabaseCleaner tries to release/rollback to a savepoint it will fail.
https://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html

The only solution to this I have found so far, is to change the strategy to truncation. This works, but it's much slower to run.

Wondering if you've encountered this issue before, and if you have other suggestions around this?

This could also have other side effects outside of running specs. Since it will commit any transaction you're in, possibly before you're done with your transaction.

If you have a base table that has no appropriate foo_id column pointing to the low-card table, no error is reported. This makes things super-confusing. We should report an error properly.

Calling #reload on an ActiveRecord model does not seem to reload the low-card association…

Steps to reproduce:

1. Have a long-running process (like Rails) using low-card tables.
2. Run a migration that adds new, nullable columns to the low-card table.

Expected results:

1. The long-running process continues working smoothly, seeing the new columns as expected.

Actual results:

1. You get an exception because there is no longer a unique index on just the old columns; instead, there is one on the old columns plus the new columns, and the long-running process doesn’t know about the new columns.

Code like this:

scope = MyTable.where(:foo => 'bar')
scope.create(:bar => 'baz')

…seems to not set :foo at all. :(

If you have a column foo in your base table, and a foo in the low-card table, low_card_tables should report the conflict with an exception. Currently, it doesn’t, and confusion results.

Code like this:

MyTable.create(:foo => :bar)

seems to be setting foo to NULL, not the string bar.