About Row change history on Self-Hosted

There is a doc saying : By default, there is a limit of 365 days of revisions for Baserow Self-Hosted, but you have the flexibility to change this limit to any other number. If you don’t want the history to be cleaned up, you can simply set this limit to 0 days.

Where should I do this?

Add a variable on docker on BASEROW_ROW_HISTORY_RETENTION_DAYS ?

Hi @michaelvips, that’s correct. It seems like the default value of BASEROW_ROW_HISTORY_RETENTION_DAYS environment value is 180, meaning that it will be kept for 180 days. You can change this to a higher (or lower) number if you wish to change the retention period.

Btw, an overview of all environment variables can be found here: Configuring Baserow // Baserow

So the documentation must be updated, because insert 0 on BASEROW_ROW_HISTORY_RETENTION_DAYS disable the row change history.

On the docs say : If you don’t want the history to be cleaned up, you can simply set this limit to 0 days. This is not true.

Hi @michaelvips, do you mean that providing 0 does actually clean up the row history?

There say : If you don’t want the history to be cleaned up, but if I put 0 the row change history stop of works.

Is the purpose to clear the history? I was thinking that this would disable the time limit in which the history will be available.

What stops working specifically? If you provide 0 as value, then the row history should never be cleaned up. Even if there was a history of 5 years old, it would then still persist. Does it work differently for you?

Yes this is what the docs says, but what happens is that it stops working, history records are no longer recorded.

Thanks for pointing that you. We’re going to look into it.

BASEROW_ROW_HISTORY_RETENTION_DAYS=0 means that there is zero retention days, aka row history will be disabled. Where did you read that it should behave differently?

The docs only say:

I believe Bram is very worried about accidentally clearing the history by setting the wrong value and wants to double-check that this “odd” 0 value won’t have side effect.

From non-technical people, who aren’t used to this kind of setting, it’s counterintuitive, indeed.
A value of -1 would have made more sense to me (no more confusion), but they seem to have used 0 instead to disable it.

There is nothing counter-intuitive about 0 for “the number of days that the row edit history will be kept” to mean it won’t be kept even for one day.

I find your statement to be very confusing.

I haven’t read the doc, but if I believe what has been said before, using 0 should not clean the history, meaning it should keep it indefinitely. Whereas what you say is that there won’t be any history, which feels contradictory with the previous statements.

There are previous comments here from other people implicating that 0 should behave as “infinite” rather than 0, even claiming this is written in the documentation. These comments are wrong.

Btw I am saying it as someone who implemented the feature.

1 Like

Thanks for clarifying!

@michaelvips Where did you quote the documentation from?

@Ambroise-DNA-PC here Row change history // Baserow

If you don’t want the history to be cleaned up, you can simply set this limit to 0 days.

On docs: If you don’t want the history to be cleaned up, you can simply set this limit to 0 days.

Ah you mean the user docs, written by our technical writer. I will tell her to correct it, thanks.