I want to automate a validation on all (or almost all) my models. That
validations should happen before every delete/destroy.
The goal is to stop the user from deleting a record if it has any
‘has*’ associations. I know that there are gems like
‘acts_as_paranoid’ that will keep the record in the DB while marking
it as ‘deleted’, but that is not what I need here.
I already have in a module the initial code that checks for
association records. The code is posted below for critique and in case
anybody is interested. The code might change, though, based on
requirements.
What I need is to know how to make all models run automatically the
method (‘dependencies_found?’ in the code below) whenever a record is
deleted without having to go to all models and include the module
manually.
Any ideas?
Thanks in advance.
module Dependable
def dependencies_found?
dependencies = self.class.reflect_on_all_associations.select {|a|
a.macro.to_s[0, 3] == 'has'}
dependencies.any? {|d| eval "!self.#{d.name}.blank?"}
end
end
Use foreign key constraints in the database for this. The Foreigner gem
will help manage these constraints.
Yes, I think you’re right and going with Referential Integrity should
be the way to go to make sure the rules are enforced at the DB level.
Although, I still would like to know how I can accomplish what I was
trying to do.
I didn’t know about Foreigner and took a look. It seems that it is
meant to be used only with MySQL and PostgreSQL. I am using MSSQL and
have not found anything useful out there as gems/plugins go for this
DB. Any ideas?
Use foreign key constraints in the database for this. The Foreigner gem
will help manage these constraints.
Yes, I think you’re right and going with Referential Integrity should
be the way to go to make sure the rules are enforced at the DB level.
Although, I still would like to know how I can accomplish what I was
trying to do.
With foreign key constraints. There is really no reason to do it any
other way.
I didn’t know about Foreigner and took a look. It seems that it is
meant to be used only with MySQL and PostgreSQL. I am using MSSQL and
have not found anything useful out there as gems/plugins go for this
DB. Any ideas?
Yes, apparently you missed my announcement a couple months ago of my
fork of Foreigner with MS SQL Server support:
The gem is available as marnen-foreigner.
I think sparkfly-foreigner also has MS SQL Server support.
meant to be used only with MySQL and PostgreSQL. I am using MSSQL and
have not found anything useful out there as gems/plugins go for this
DB. Any ideas?
you can run a sql command in your migration to generate a foreign key
constraint yourself, look at activerecord execute
Yes, I think you’re right and going with Referential Integrity should
be the way to go to make sure the rules are enforced at the DB level.
Although, I still would like to know how I can accomplish what I was
trying to do.
With foreign key constraints. There is really no reason to do it any
other way.
But it would provide me with knowledge of Rails internals I don’t have
right now that might become useful in the future.
That’s exactly what I did yesterday when I realized Foreigner worked
only with MySQL and PostgreSQL and got it working but Foreigner seems
to help you along the way and make things easier and more ‘Railsy’,
which was what I was looking for.
Got it working. Thanks for the tip. It would be great if ‘schema.rb’
got updated with the code for the FK constraints, though.
I found this (Tickets - Ruby on Rails - rails
4347-add-foreign-key-support-to-migrations-and-schemarb-dump) from the
original creator of the gem you forked but I’m not sure how I would go
about using the feature.
Yes, I think you’re right and going with Referential Integrity should
be the way to go to make sure the rules are enforced at the DB level.
Although, I still would like to know how I can accomplish what I was
trying to do.
With foreign key constraints. There is really no reason to do it any
other way.
But it would provide me with knowledge of Rails internals I don’t have
right now that might become useful in the future.
Well, looking through the source code is never a bad thing. Just bear
in mind that the DB is in the best position to do data integrity
checking.