Functionality and performance questions, and approval recommendation

[jmkristofzski]

I apologize in advance if these questions don't belong here, I'm quite curious about the functionality and performance of this gem. I'm mainly asking this questions from the viewpoint that most of my records would be accessing the most recent version only, and very rarely needing to review past changes.

1. It's difficult to tell from the documentation, does this save the original record, then apply changes every time it is loaded? Or does it save the most recent and contain a log of all past changes? According to the documentation it looks like the former ("attr": "new value" is mentioned in the log format). If the former, what kind of performance impact is there when attempting to view the most current version of a record (e.g. 10 versions vs 1000 versions when attempting to load a single record)?
2. In regards to question 1, if the most recent version is saved and all past changes are logged in the log_data column would there be any noticable benefit to saving the log_data in a separate table, then creating a relationship table between log_data and the table you want to track? e.g. An "Event" has the most recent version saved, as the most recent version is saved it creates an entry in EventLogsRelationship, and the the Event's previous data is saved to an EventLogs entry. I understand this is NOT how the gem works now, I'm mainly curious if there would be a potential performance increase with this method, specifically because it wouldn't load the log data unless it's called.
3. Is it possible to add an "Approval" feature where someone such as an Admin or Mod must approve changes prior to them being implemented? I feel like this would be similar in some ways to the "Cooldown Time" someone suggested.

[palkan]

Hi @jmkristofzski!

It's difficult to tell from the documentation, does this save the original record, then apply changes every time it is loaded? Or does it save the most recent and contain a log of all past changes?

The first one: the log is stored along with the most recent record's state. So there is no overhead when loading the current version.

In regards to question 1, if the most recent version is saved and all past changes are logged in the log_data column would there be any noticable benefit to saving the log_data in a separate table, then creating a relationship table between log_data and the table you want to track?

You can check the benchmarks here.

We're interested, first of all, in memory usage. Of course, loading the whole history provides an overhead. But this overhead is much less than loading logs from a separate table (as PaperTrail does, for example).

One way to eliminate the overhead completely could be to add log_data to ignored_columns and explicitly select it when necessary.

Is it possible to add an "Approval" feature where someone such as an Admin or Mod must approve changes prior to them being implemented?

The log entry is created in the database, so it would be quite difficult to implement such feature.

[jmkristofzski]

Thank you for the response!

Taking all that into account I think I'll set up the approval process outside of the gem, and once approve make use of the gem to implement the changes.