Re: Dropping a table does not drop all constraint validations

2019-03-13 Thread 'Mike Pastore' via sequel-talk
On Tuesday, March 12, 2019 at 2:08:01 PM UTC-5, Jeremy Evans wrote: > > Change committed: > https://github.com/jeremyevans/sequel/commit/d198cc1851c7cba380632a35f88ca193c346d6ae > Fantastic news. Thanks Jeremy! Mike -- You received this message because you are subscribed to the Google

Re: Dropping a table does not drop all constraint validations

2019-03-06 Thread Nick Appelmans
That fixed my problem. Long story short on the model name, I actually tried to rename from Auth_user to AuthUser at your suggestion and ran into the NameError so I changed it back and ran into the name error again! Setting the :class for each of the associations seems to have fixed this (I thought

Re: Dropping a table does not drop all constraint validations

2019-03-06 Thread Jeremy Evans
On Wednesday, March 6, 2019 at 10:42:21 AM UTC-8, Nick Appelmans wrote: > > 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

Re: Dropping a table does not drop all constraint validations

2019-03-06 Thread Nick Appelmans
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

Re: Dropping a table does not drop all constraint validations

2019-03-02 Thread Jeremy Evans
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 >