can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

In T15126#3158, @avivey wrote:

can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

No, we should basically follow the two parts per @Matthew.

In T15126#3165, @Cigaryno wrote:

In T15126#3158, @avivey wrote:

can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

No, we should basically follow the two parts per @Matthew.

FWIW I don't think @avivey implied not doing two parts? I think they were just objecting to part 2 being mandatory after a month, and I for one agree. I've at times not updated Phabricator for > 1 month, and having data deleted unexpectedly after being brought up to date would be unexpected. Not specifically Chatlog in my instance as I've never really used it or Conpherence much, just commenting on data deletion in general. I don't think it's critical to delete data after a 1 month period.

I think it would be totally reasonable for Phorge to just not reference the tables after fully removing it but leave them in the database indefinitely, optionally adding a maintenance script or similar to clean up old data.

I'm not sure what Upstream did in regard to cleaning up old tables if it did, but I know in general it was 'more difficult' to permanently remove data, with appropriate warnings in place.

There's a difference between deleting data as a Phab/Phorge admin (which is done via the bin/delete script, and prints out a massive warning about it potentially breaking stuff and generally being a bad idea), and schema migrations done as part of an upgrade, which would happily delete data without a second thought.

That being said, we could potentially modify the migrations such, that for new installations the table would get created as TEMPORARY, making it disappear on it's own, but not affecting existing installs.

Letting a table with unused data potentially linger indefinitely in the database is IMO better than dropping a table with unused data which someone might still want.

The old Chatlog data will be kept while removing Chatlog.