We are planning to make some of the tables audit enabled in our Rails3 application. We did look at paper_trail and it seems to store all the versions, but I wasn't sure if there was a mechanism to find the difference b/w what field changed within successive versions. Would it be possible to do with the paper_trail gem or should I use something like vestal_versions for this capability?
You can achieve that with paper_tail gem. If you add an object_changes text column to your versions table, you can use the version.changeset method to retrieve it. If you haven't yet, I recommend going through 'Diffing Versions' section in https://github.com/airblade/paper_trail
p.s. I am using paper_trail in one of my projects currently.
Related
I'm using the gem paper_trail for keeping track of versions. I wonder, is there any way to create some kind of activity news out of the models it's been included into? For example, I've added it into the models Commentary, User and Article. I want to be to get a list of the latest changes of these models and create something like news of activities:
user A has created a new Category
user B has edited an Article
admin had added a new Article
etc
Is it possible? And how? Seems like yes, but how exactly? Note that, I don't want to retrieve that kind of information from all the models I've included the gem into, but only from the ones I want to.
Since you want it by the user, you should integrate https://github.com/ankit1910/paper_trail-globalid to link the whodunnit part.
PaperTrail::Version.where_object(attr1: val1, attr2: val2)
NOTE: paper_trail gem is for auditing.
Do not forget to check your indexes on your database since relational databases slow as your no. of indexes increase.
Based on my experience with [spree][1] framework and a similar gem, versions table was the largest we had and it grew quiet fast. You may face similar challenges in maintaining this table and adding indexes may cause it to slow down.
My suggestion would be to use a Redis like store to maintain a list of 10 or so recent updates per user which the user may be notified of instead of querying MySQL (essentially caching)
I am new to RoR. I met one question which is: some active records may not needed to be searched for in database(let's say they are expired). I don't want to delete it from database because it is associated with other models. Also since it is expired, I don't want it to be updated. Is there any way to handle this situation in rails?
A Rails plugin to add soft delete.
This gem can be used to hide records instead of deleting them, making them recoverable later.
https://github.com/ActsAsParanoid/acts_as_paranoid
There are different ways. But I recommend you to use https://github.com/radar/paranoia
You can find a good screencast here: https://gorails.com/episodes/soft-delete-with-paranoia
It is really easy to add to your app. Just add the gem to your Gemfile and add acts_as_paranoid to your model.
Your question(s)
Avoid querying a subset of your data:
*For this one ought to utilize ActiveRecord's scopes. Specifically use a default scope. Ref here http://api.rubyonrails.org/classes/ActiveRecord/Scoping/Default/ClassMethods.html. Incidentally, this is the mechanism that the soft-delete gems I have come across utilize to hide soft-delete records
How to prevent updating the records:
Not sure how you mean. What about the records that you are not going to be using will be (automatically?) updated?
In NHibernate it's possible to work with versions using the same table and just add a version number column to that table see here. For severe performance reasons I'd like that logic to be contained in the same table not in a collection table. Is there anything like that for Rails or do I need to roll our own?
I have looked at all the options available like audited, vestal_versions, paper_trail and must say I am disappointed in all of them. They are not only cumbersome to use the right way but also performance bottlenecks. To restore a version in paper_trail I have to do 3 queries to the database to fetch the data to restore and then another query to update.
Do you mean Optimistic Locking?
I'd like to be sure if vestal_versions does support versioned associations (it seems like it doesn't) before switching out to another versioning gem that can support versioned associations e.g => has_versioning. I haven't looked at the code yet but I couldn't find anything related with versioned associations from the readme file or the issue section on github. Help would be appreciated!
(At the moment of writing this) There is an associations branch in the official vestal_versions repository, It is still a basic idea and isn't merged yet in the master branch. So I decided to go with another versioning gem, specifically acts_as_revisable following the instructions in this blog post.
I'm looking for something that appears to be very close to your needs. But I don't need to revert the associated objects, just to record them. I was thinking of handle it in a nosql way. So I can save the model version and the associations would be embedded documents.
So I can compare versions in a more comprehensive way. Right now I use paper_trail, but as it can't handle associations, it's not possible to store the tags associated to a model and see how it changes through time.
If all I have is one model (for example Wiki) and want to save it along with its versions, I could use acts_as_versioned plugin which stores the wikis in "wikis" table and its versions in "wikis_versions" table. This is plain an simple even if I want to moderate the latest version before showing it to the public using a field as status with "pending review/ published".
What's the best way to handle Wiki with associations (for example attachments, assets,..) which also have versions? And how would you moderate it? Do you create a new version to wiki even though only its association is changed just to keep the flow going, if so what about other associations?
What's the best way to handle it with little db overhead?
Thanks in advance.
I have used both acts_as_versioned and acts_as_audited.
I prefer the latter because it uses a single table. Using acts_as_versioned we've had issues with changes to versioned tables requiring extra migrations => this adds extra complexity to our build and deployment process.
Richard Livsey has a nice plugin for this that works with acts_as_versioned.
http://github.com/rlivsey/acts_as_versioned_association/tree/master