[SOLVED] Installation History Auto cleanup

Hello,
I have noticed that when using the install feature this will add the row for the module/ocmod/ etc installation and that's Good and OK,
But I also noticed that If we Re-install the same for whatever the reason (normally an updated version) this will be created as a second Row in the table.

So understanding the visual logic created here:
The use have knowledge of the installation history as the dates and time will be different

The problem:
The user is able to Hit delete on a Previous installation and this will cause an issue as the same file/filepath are being use by the latest installed and these will be deleted
There will be an accumulation of records of the 3 used tables in the DB that is not being used by the system

Is there any known method (mysql trigger, php code) tested that solve this bad practice "issue" already ?

thanks.

Remove the old one before installing the new / updated one.

OCMOD (in my opinion) best feature (above VQMOD) in that when you install it makes a record of all the files installed in the database and when you uninstall it, it removes all those files.

by mona wrote: ↑

Thu Apr 06, 2023 8:03 pm

Remove the old one before installing the new / updated one.

OCMOD (in my opinion) best feature (above VQMOD) in that when you install it makes a record of all the files installed in the database and when you uninstall it, it removes all those files.

Hi, Yes I do agree, but If you remove the old one, any conf you had will be lost so that's not ideal

haxcop wrote: ↑

Thu Apr 06, 2023 8:34 pm

Hi, Yes I do agree, but If you remove the old one, any conf you had will be lost so that's not ideal

Shouldn't be. Most config is held in the database and uninstalling will only remove the files. So when you reinstall then the settings should still all be there.

Well it's not certanly true I've done the test and the configuration ended corrupted or basically gone...
Other question, where does exactly the table history takes the information from? which table in the DB?

haxcop wrote: ↑

Thu Apr 06, 2023 10:50 pm

Well it's not certanly true I've done the test and the configuration ended corrupted or basically gone...

NO OC VERSION
As grgr said, it should not be so. You will have to discuss that with the extension developer. Configs should not be effected. So either you did it wrong or the developer has used the wrong table in the database.

haxcop wrote: ↑

Thu Apr 06, 2023 10:50 pm

Other question, where does exactly the table history takes the information from? which table in the DB?

You already sent a screen shot .. extension install

by mona wrote: ↑

Thu Apr 06, 2023 11:20 pm

haxcop wrote: ↑

Thu Apr 06, 2023 10:50 pm

Well it's not certanly true I've done the test and the configuration ended corrupted or basically gone...

NO OC VERSION
As grgr said, it should not be so. You will have to discuss that with the extension developer. Configs should not be effected. So either you did it wrong or the developer has used the wrong table in the database.

- Don't get me wrong, the OC VERSION is 3 as I am in the current forum, doesn't matter much which version of the 3 right? the DB still same structure.

haxcop wrote: ↑

Thu Apr 06, 2023 10:50 pm

Other question, where does exactly the table history takes the information from? which table in the DB?

You already sent a screen shot .. extension install

Yes I did but Upon Removing one row from it in the db.table, and refreshed the shop I could still look at it in the history

haxcop wrote: ↑

Fri Apr 07, 2023 12:12 am

but Upon Removing one row from it in the db.table

That is a good way to destroy your database. You can not (well you can obviously but it is not wise to) just delete a row in the database, other things are usually connected to it.

haxcop wrote: ↑

Fri Apr 07, 2023 12:12 am

I could still look at it in the history

By this you mean the modification list (admin => extensions => modifications) ?
That would be the modification table

by mona wrote: ↑

Fri Apr 07, 2023 12:22 am

haxcop wrote: ↑

Fri Apr 07, 2023 12:12 am

but Upon Removing one row from it in the db.table

That is a good way to destroy your database. You can not (well you can obviously but it is not wise to) just delete a row in the database, other things are usually connected to it.

haxcop wrote: ↑

Fri Apr 07, 2023 12:12 am

I could still look at it in the history

By this you mean the modification list (admin => extensions => modifications) ?
That would be the modification table

Good Youtube video

-
Cool - I have done a MySQL Trigger that solves this issue.
Thank you

You are welcome on both counts

Glad you have it sorted and thanks for adding [SOLVED]