Wanting to use this with Livewire live form saving

[christoferd]

I'd love to use this with Livewire live form saving.

For example: The app has a calendar booking form that automatically saves edits made in form fields on existing records.
This means the form may save 10 times in 60 seconds. And not necessarily to the same model.

If every change were saved to the database, it would create millions of records in a short amount of time.
Even if I only stored the differences/changes, it would be a lot of records, maybe not so much data.

Issue: I want to keep the main database fast and lean.

Solution?

1. Use a separate database just for Activity? Maybe sqlite3
2. Merge similar records recorded at similar times? By making sure the Activity tracker does not store every single change to a separate record. Idea here is to create a time slot of X seconds. When storing, it will check if there was a previous record within last 300s. (this could be cached) The changed data can be merged. This limits to only one activity record per user per each edited booking per 300s.

Context: The visible calendar has Bookings with its own details, and related to Tasks, Charges, Transactions, Clients, and Vehicles

What would you do?
Have you had to sove this yourself?

[christoferd]

Interesting that nobody has chimed in on this idea. Isn't anybody using Livewire and activity logging?

I have updated a project lately to reduce the number of activity logs by having the logger always check the most recent activity by the same user and for the same object type. If it's within X minutes it will just merge the data. Therefore, a User could use a Livewire form that keeps updating a record on-the-fly, while only storing one activity record every X minutes.

e.g. One Activity record every 5 minutes for that user and same record type.
e.g. The user could be editing the app configuration settings, where toggling options could be saved as they go without needing to press a Save button.

There's more overhead for the extra DB calls, but unless the activity calls are cached in between, then there's no avoiding this that I can see. I guess, to improve, each activity storage call could be cached at the Library/Model level for X minutes, then the look up process would check the recent cache instead of running DB calls.

[christoferd]

This could be abused, I guess. Where a user knowing how this works could make a change at the right time, do something in the system, then change it back so that the merged activity has the new data and not show the old :-(

[christoferd]

Another idea is to just use Monologger to store all changes, so that each Model could have a dedicated file. The file could be chopped up by way of folders for each model type, or by filenames. Many options with this method. Reduces overheads of using DB for no reason.