Adding debounce time to avoid spamming changelog creation

[zocoi]

Usecase: We have a Blog model which get frequent minor updates for the content column as the editor keeps typing with the CMS autosave feature (every 5s) and we don't want to create log to capture tiny changes. The content text could be big so we need to save space. I came up with a concept similar to https://underscorejs.org/#debounce. The idea is that if the several logs came in within a time period, we only keep the latest one and discard the rest.

{
    "h": [
        {
            "c": {
                "content": "Content 1"
            },
            "v": 1,
            "ts": 0
        },
        {
            "c": {
                "content": "content 2"
            },
            "v": 2,
            "ts": 100
        },
        {
            "c": {
                "content": "content 3"
            },
            "v": 3,
            "ts": 101
        }
    ],
    "v": 3
}

becomes

{
    "h": [
        {
            "c": {
                "content": "Content 1"
            },
            "v": 1,
            "ts": 0
        },
        {
            "c": {
                "content": "content 3"
            },
            "v": 3,
            "ts": 101
        }
    ],
    "v": 3
}

Notice that version 2 is gone

Please give feedback and help optimize the sql part.

Right now the code doesn't care if columns are edited by different responsible_ids but that could be easily added.

[palkan]

I like the idea. Thanks!

But we definitely need tests)

[palkan]

I think, it's better to handle debounce before adding a new version instead of adding a new first version first and than merging it with the previous.

So, on line 231 we can do:

IF debounce_time IS NOT NULL AND version->>'ts'::bigint - NEW.log_data#>'{h,-1,ts}')::text::bigin <= debounce_time
  # merge new version with the previous one
  version = logidze_merge_version(NEW.log_data#>'{h,-1}', version)
  # remove the previous version from log
  NEW.log_data = jsonb_set(
            NEW.log_data,
            '{h}',
             NEW.log_data->'h' - (size -1 )::text
          );
END

[zocoi]

thanks for the brilliant suggestion, I made the change accordingly and added some tests

[palkan]

Why do we need this step?

We're merging changesets on the next line.

The only key that could me missing in the new version is the meta key ("m"); but I think merging meta information could lead to undesired behaviour: for example, if we track responsibility than we should care only about the last meta information (and its absence).

[zocoi]

this will merge the v, ts, (meta) m and (responsible_id) r along with the changesets c so we always get the latest ones. However, || can't do the deep merge for the changeset so we need to do it separate in the next line.

For meta m, we can do a deep merge but just like you said, I don't think it's necessary

[palkan]

Let's add a measurement unit to the description

[palkan]

@zocoi Let's add a changelog entry and update the readme with the new feature description. And we're almost done)

[zocoi]

@palkan @charlie-wasp I changed the version number logics when merging logs, I kept the previous version number for consistency. Previously 1->2->3 was merged to 1->3, now it should be 1->2.
Also added changelog and updated README, let me know what else should be done.

Thanks

[palkan]

Let's leave the change log entry under master section. We don't know the date and version of the release this feature will be included)

[palkan]

Please, add your Github handle here (and in the bottom of the document)

[zocoi]

thanks, it should be done

[palkan]

Add js lang attributes here and in the snippet below to make RuboCop ignore these snippets (right it considers them as Ruby code)

[palkan]

Great job! Thanks!

Will release a new version soon