I don't know if this is relevant or I should make a separate post for this
topic but just in case it is: I renamed a model (AuthUser to Auth_user),
dropped the table (authusers), recreated the table with the new model name
(auth_users) and found that the old model name was still being referenced
when Sequel was working out the associations. Here is part of the error
message...
2019-03-06 17:42:10 - NameError - uninitialized constant
MemberTracker::AuthUser
Did you mean? MemberTracker::Auth_user (this happened when attempting to
find the associated class for
#<Sequel::Model::Associations::ManyToOneAssociationReflection
MemberTracker::Log.many_to_one :auth_user, :key=>:a_user_id>):
/app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in
`constantize'
/app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in
`module_eval'
/app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/inflections.rb:114:in
`constantize'
/app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/associations.rb:69:in
`block in associated_class'
/app/vendor/bundle/ruby/2.4.0/gems/sequel-5.5.0/lib/sequel/model/associations.rb:563:in
`block in cached_fetch'
....
I tried to use :reload => true to clear the cache but I'm not using it
correctly. I tried...
aus = Auth_user.all
aus.each do |au|
au.logs(:reload => true)
au.logs.each do |l|
...
If this is an unrelated issue, I can repost this question which most likely
has something to do with my misunderstanding of how to clear a cache.
Thanks for any thoughts,
Nick
On Saturday, March 2, 2019 at 12:13:16 PM UTC-8, Jeremy Evans wrote:
>
> On Saturday, March 2, 2019 at 9:58:16 AM UTC-8, Mike Pastore wrote:
>>
>> Jeremy,
>>
>> Just to confirm something. It appears that dropping the table :foo does
>> not also drop all constraint validations for table :foo. So my down
>> migrations should all look like this:
>>
>> down do
>> drop_table(:foo)
>> drop_constraint_validations_for(:table=>:foo)
>> end
>>
>> In order to prevent the sequel_constraint_validations table from becoming
>> "cluttered." Or am I missing something?
>>
>> This is particular relevant if you later recreate the table with
>> similar-but-slightly-different constraint validations. I had a case where I
>> created a constraint validation with :allow_nil=>false, subsequently
>> dropped the table, then later recreated the table and the same-named
>> constraint validation but with :allow_nil=>true. This led to a situation
>> where the former rule was still in effect when I expected the latter.
>>
>> I could also see a situation where defunct constraint validations persist
>> in the sequel_constraint_validations table—for a dropped column, say—and
>> get applied by the model plugin even though they are no longer valid.
>>
>> It would be nice if dropping a table or a column automatically removed
>> applicable constraint validations, if that's even possible. Just a wishful
>> thought.
>>
>
> It is expected that currently you have to drop the constraint validations
> manually. However, I think it makes sense to drop them automatically, and
> it should still be backwards compatible (the
> drop_constraint_validations_for call should be idempotent). If you would
> like to work on a PR for the constraint_validations extension, that would
> probably speed up the process, but I'll try to get to it sometime in the
> next few releases.
>
> Thanks,
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
