Hello, a few questions for the experts

[pri...@gmail.com]

Hi, I've been tasked with making a django app that will need to support versioning of some documents.

I've been looking at your code to familiarize my self how to approach versioning.

I see you keep two models, one for current version and the other for past revisions? That's what I was thinking too ...

What I need to know though... you use content type to make a connection to the model which you are versioning, which is great I guess, so this app supports versioning of *any* model basically, but I will know which models I want to version (only one, maybe two), so I would remove this extra step, to simplify the queries a bit if nothing else ...

How heavily would this break your app? I guess just removing the field from the model will not break it too much but I don't know exactly where do you use this field ... so do you think it's too much work to remake your app to work like this and secondly, would you even recommend doing this or is it unnecessary.

What I am making will be an enterprise app for a fairly large firm with about 1000 concurrent users using it, so it needs to be scalable at least a bit.  and secondly do you think there are any other potential bottlenecks with using your app?

Looking forward to hear your thoughts

or anyone else if they got an opinion ...

kid regards

pr

[Dave Hall]

So long as you use integer primary keys for your models, the query performance of django-reversion won't be too bad compared to just a straight foreign key. Things reversion is slow on are:

• Versioning models with a string primary key.
• Finding deleted models for recovery.

If neither of these things affects you, it should be a good fit. Then it's just the usual question of whether to use 3rd party code versus your own, which is a decision only you can make.

--
You received this message because you are subscribed to the Google Groups "django-reversion discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-reversi...@googlegroups.com.
To post to this group, send email to django-r...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-reversion.
For more options, visit https://groups.google.com/d/optout.

[pri...@gmail.com]

ok thank you very much ... i will use integer primary keys so the first one is not a problem but second one, i guess recovering past revisions will be supported although not the main functionality and if it's a tad slower, probably won't matter that much as long as it works ... 

as far as the 3 rd party code goes, I will probably make my own stripped down version ... for the sake of stability and simplicity. this is what i usually do unless it's dead simple app.

ok thank you very much..

regards

[pri...@gmail.com]

the only problem i need to solve is ... my "document" consists of several models and some M2M relations with intermediary models ...

how would one go versioning such system, each model separately?

[Dave Hall]

If your document is made up of those discreet relations, then you could get away with saving the entire set of models as list passed to django.core.serialization.serialize

Then you just index the versioned snapshot under the "main" model's pk.