custom Version models per model?

Ahoy @etianen ,

I googled for a while and couldn’t find any information on that:

I was wondering if it would be helpful/clever/possible to create per model Version models, i.e.:

@reversion.register()
class Person(models.Model):
    ...

would yield a myapp_person_version table, or a reversion_myapp_person_version or similar. Or alternatively add a function argument to register() to pass in a different Version-model for specific models?

My reasoning here being that that single reversion_version table is gonna grow quite rapidly in my scenario and at least based on my naive database knowledge I think it would be helpful to be able to spit it into semantically seperated tables.

Cheers

[etianen]

Yes, you would lose historical data when you remove a field. However, if you’re not going to be migrating historical data, it rapidly becomes unparseable by the current version of the app. You’d have to make sure that your migrations are all reversible with no data loss. That way you can migrate your current and historical data back and forth.

A general-purpose solution for lossless, migrateable historical data does not exist. django-reversion makes a best effort, but at some point if you make a radical schema change your reversion history has to be deleted or tediously manually migrated.

So if you truly need a lossless historical data record, you’ll need a careful, custom solution.

On Tue, 12 Nov 2019 at 10:24, Andreas Nüßlein [e-mail] wrote:

But if it participated in the migrations, you’d lose historical field data if you also removed a field. Or would you never remove fields/columns, but only ever add? I do understand that you have the same problem now: if i remove a field and i want to roll back an old version, where would that extra data from the serialized json go, either way 🤔 . But at least in the JSON the data would still be there.

I guess you’re right about the performance. But still: the queryability 🎉

Hmmmmh you’ve given me a lot to think about 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/etianen/django-reversion/issues/808?email_source=notifications&email_token=AABEKCF3YGM6WBB2NNK2BQ3QTJ77JA5CNFSM4JKUHOI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZYTLY#issuecomment-552831407, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEKCG7SQR2DV7TPFLGASDQTJ77JANCNFSM4JKUHOIQ .

[andreasnuesslein]

But if it participated in the migrations, you’d lose historical field data if you also removed a field. Or would you never remove fields/columns, but only ever add? I do understand that you have the same problem now: if i remove a field and i want to roll back an old version, where would that extra data from the serialized json go, either way 🤔 . But at least in the JSON the data would still be there.

I guess you’re right about the performance. But still: the queryability 🎉

Hmmmmh you’ve given me a lot to think about 😃