GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Hi all, I've got a question about this gem:
Supposing I have these models in Rails:
class Foo < ActiveRecord::Base
has_one :bar, :dependent => :destroy
class Bar < ActiveRecord::Base
Then I do:
Foo.find(6).destroy # It ends up in Foo::Archive with id 6 and Foo.find(6).bar ends up in Bar::Archive
Then, much later, someone creates another Foo and unluckily it has id 6 and deletes it:
Foo.find(6).destroy # Primary key collision
What happens to the referential integrity of the archive tables?
Sadly this library is not supported anymore.
But because I had to dig in the code, I can tell you there is no integrity check.
The gem assume that id are affected incrementaly (eg : with AUTO_INCREMENT in MySQL).
Can we assume this for any database that rails has an adapter for? For instance Postgres?
I'm pretty sure we can assume it for SQL databases (including PostgreSQL), but I have no idea for non relational databases (anyhow this library has no adapter for them).
Cheers elmatou! Now I know that I can use in my app a version of this gem+mover+also_migrate and that I hacked to work with PostgreSQL and Rails 3.1 reversible migrations. I've submitted all of my changes. The annoying thing, we realised only after modifying acts_as_archive that it was going to be easier (in our case) to write a simpler version of acts_as_paranoid, which took an afternoon.