Short after posting how to get django-rcsfield running, Marty Alchin posted to mention AuditTrail, and ask if I could see any compelling reasons to use something like django-rcsfield instead of AuditTrail.
If you look at the two, they perform very similar services:
django-rcsfield uses a variety of version control systems (Git, Bazaar, Subversion) to maintain a complete version history of a textfield.
AuditTrail uses the database to maintain a complete version history of a model (although it doesn't necessarily play well with relations).
Last night I set up an app I am working on to use django-rcsfield, and it took a bit of sleuthing to understand. On the other hand, just now I was able to replace django-rcsfield with AuditTrail in about five minutes. Where rcsfield was opening up weird cross-platform issues related to Git, AuditTrail just worked. Where rcsfield was causing my small vps to lag horribly--again--AuditTrail just worked.
I can imagine some specific situations where having the full power of merging, cloning, branching, etc, would be a real asset, but I suspect such apps are a small minority of all the applications that benefit from some degree of versioning. For those not in that small bucket, AuditTrail seems like the best existing solution.
Setting AuditTrail up was a few short steps:
Paste the code at the bottom of the AuditTrail wiki entry into a file named
audit.py, somewhere in your Python path.Import
audit.pyin yourmodels.pyfile.from django.db import models import audit
Add an AuditTrail field to your model definition.
class MyModel(models.Model): title = models.CharField(max_length=200) text = models.TextField() history = audit.AuditTrail()
Sync your database.
python manage.py syncdb
Profit.
>>> from models import MyModel >>> MyModel.create(title="hi",text="some value") >>> a = MyModel.objects.all()[0] >>> a.text = "some other value" >>> a.save() >>> a.history.count() 2 >>> a.history.all()[0].text "some other value" >>> a.history.all()[1].text "some value"
Although I really appreciate the hard work that has gone into django-rcsfield, I think that AuditTrail is simply an easier approach to versioning data at this point in time. I do think there is room in the world for both of these approaches, and that some apps will benefit more from using django-rcsfield than AuditTrail, but I'd recommend starting with AuditTrail and only transitioning over if and when circumstances demand it.
Hopefully both of these projects will continue to improve, but for the time being AuditTrail is the way to go unless you need more advanced VCS functionality like merging, pushing, pulling or cloning.
Just wondering if you've seen django-reversion? It seems a little easier to implement than AuditTrail and is usable on thirdparty apps as it doesn't require editing the model (you register a model instead). I guess I'm curious as to how it compares.
Looking at the source, the approaches of django-reversion and AuditTrail look very similar, although django-revision seems more fleshed out and has support for some things that AuditTrail doesn't (can version uploaded files/images, which seems pretty neat).
My impression is that AuditTrail will be a bit lighter performance wise, since it doesn't rely on a middleware, but has fewer features. For someone in my situation (trying to version a textfield, or a few textfields and charfields), they seem to offer just about identical functionality.
If I get some time I'll try to run some performance tests later.
I find it rather confusing that you compare those two with each other -- it's like apples and oranges. django-reversion is a much better simile to audittrail when it comes to versionizing data in a database. rcsfield saves the history on the disk and you really are surprised that the database solution is not bringing your vps on its knees.
Jannis,
Although I agree that their implementations vary greatly, it seems to me that they are addressing the same problem: storing versioned data. If I want to store a history of a textfield, all three of these (django-reversion, AuditTrail, and django-rcsfield) can do that.
I compared them because they could both solve my problem at hand, and I needed to pick one. ;)
I'm not quite sure how to parse your last sentence, but either you're saying it is surprising that the database solution works better on the vps, or you're saying that it isn't surprising that the database solution works better. I can imagine reasonable arguments either way. :)
Writing an application where I needed revision information about certain fields of a model I went with making a secondary model for revisioned data with a one-to-many relationship. A one-to-one relationship between the same models served as a pointer to the active revision. I found this approach much more flexible as I would store only raw markdown in the revision model and rendered html in the actual model class:
I believe this would be a better approach.
Thanks for pointing out the revisioning libs! Haven't been aware of the django-rcsfield