Tracking many_to_many relationships

[danicuki]

Is there any way to track many_to_many relationships with papertrail? (in this case track deletes and inserts on the relationship table)

[airblade]

Yes and no. Although I don't think that's quite what you're after.

The question is can we do:

@book.version_at(1.week.ago).ratings      # has many
@book.version_at(1.week.ago).isbn         # has one
@book.version_at(1.week.ago).publisher    # belongs to

-- and get the associated records back as they were at the time.

The problem has two axes: the three types of relation on one and the three states of the associated record on the other (record is same entity with/without updates; record didn't exist at the time but was subsequently created; record did exist at the time but was subsequently deleted).

It's easy where the associated record was the same entity or didn't exist then. Having said that, PaperTrail could do more of the work for you. It's trickier where the associated record has been subsequently deleted, particularly for has one and has many. All the information is there in the versions table but currently you can't get at what you need without doing a table scan.

I'm therefore thinking about having another table to record assocations when they are destroyed. I'm about to go on holiday so it might be a while, but I hope to report a solution to this at some point.

[lancejpollard]

What about integrating something like acts_as_archive into this? It's a fairly thin library that overrides the delete methods to insert the deleted records into an archived_x table, which means you don't need the after_destroy callbacks and whatnot.

http://github.com/winton/acts_as_archive/blob/master/lib/acts_as_archive/base/destroy.rb

It would be awesome if PaperTrail could handle all delete cases, it does everything else great!

[airblade]

Thanks for the idea. I'll take a look.

[warrickcustomhomes]

@airblade: in a recent blog post, you mention perhaps making PaperTrail aware of requests or transactions, similar to Efficiency's TransactionID middleware. Were you thinking about generating a UUID for each transaction, making that available in the request's environment variable, then storing the transaction ID in the PaperTrail table if stuff is changed? This way, associations could be identified as records having the same transaction ID, and could therefore be reified? If so, I might end up taking a crack at this in the near future for a Rails app I'm developing...

[airblade]

@ScrapCoder: that's exactly what I was thinking. Good luck!

[batter]

Closed in favor of PR #439, which was just merged.