Open dmeranda opened 8 years ago
Just poking around in the code I added a one-line patch which appears to work. But as I really don't know how all the code works I have no idea if this is the correct thing to do.
--- lib/schema_associations/active_record/associations.rb-1.2.3 2015-11-10 05:01:07.607501051 -0500
+++ lib/schema_associations/active_record/associations.rb 2015-11-14 01:35:01.260257705 -0500
@@ -80,6 +80,7 @@
def _load_schema_associations_associations #:nodoc:
return if @schema_associations_associations_loaded
@schema_associations_associations_loaded = true
+ return if abstract_class?
return unless schema_associations_config.auto_create?
reverse_foreign_keys.each do | foreign_key |
It would be nice to have a clean way to have the functionality of "schema_associations" in a base model class when schema associations are turned off globally and have it inherited. For example:
# app/models/schema_plus_base.rb
class SchemaPlusBase < ActiveRecord::Base
self.abstract_class = true
schema_associations
end
# app/models/color.rb
class Color < SchemaPlusBase
end
In the example above, schema_associations does not work in the "Color" class.
@ScottSmix i'd be happy to accept a PR. No time to dive into it myself though.
If you have a model class that is derived from an abstract class then the automatic determination of the table name does not appear to work. Consider that we have a very minimal table called "colors", with no foreign keys, then with the model classes:
Without schema_associations you can enter:
But with schema_associations listed in the Gemfile; using the default configurations, you get an error:
Interestingly, if you immediately retry the same thing it works:
There are no problems if do-nothing abstract base class is not in the mix. The only schema_plus gems that are loaded are:
If I had to guess it seems like an initialization ordering thing, but I don't know the code well enough.