Audited 5.0 discussion - what should we drop?

[tbrisker]

Since we have already merged one breaking change, perhaps this is a good opportunity to make a bunch of other breaking changes and release version 5.0?
Since we don't have any other communication channel at this time, I'm opening this issue to discuss this. (I just registered the #audited channel on freenode if anyone want to chat via IRC.)

I personally think we should drop support for Rails 4.x and Ruby < 2.3, but there are most likely other things we can change.
Users needing support for older versions will still be able to use the 4.x branch.

[tbrisker]

@danielmorrison @fatkodima @grosser @hernanat @codenamev @lmansur @tekin @JonathanWThom - Since you have been actively contributing lately, would be happy for your inputs as well 😃

[hernanat]

I am mobile at the moment, but I definitely do have some input for this. Will respond when I am in front of a computer, thanks for tagging me :)

[grosser]

drop ruby <2.3 and start using frozen string + rubocop :)

[fatkodima]

Maybe also we can reduce complexity of all logic related to db updates? For example, at least by merging all this files https://github.com/collectiveidea/audited/tree/master/lib/generators/audited/templates into one initial migration?

[fatkodima]

Probably, this can be merged as well #406, if this is a pretty frequent usecase.

[grosser]

merging the migrations sounds nice, but I'd prefer to still keep at least 2 so it's obvious what is to do when adding a new migration

…

On Sun, Apr 1, 2018 at 9:03 AM, fatkodima ***@***.***> wrote: Maybe also we can reduce complexity of all logic related to db updates? For example, at least by merging all this files https://github.com/ collectiveidea/audited/tree/master/lib/generators/audited/templates into one initial migration? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#430 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAsZ81f2zIDmrT0hc7fL513FDOpTaBtks5tkPpTgaJpZM4TC3LU> .

[grosser]

drop rails 4.0 and 4.1 support too ...
#431

[fatkodima]

I'm also a bit concerned about usefulness of this part:

If you're using PostgreSQL, then you can use rails generate audited:install --audited-changes-column-type jsonb (or json) to store audit changes natively with its JSON column types. If you're using something other than integer primary keys (e.g. UUID) for your User model, then you can use rails generate audited:install --audited-user-id-column-type uuid to customize the audits table user_id column type.

It is not that hard to edit generated migration file by yourself without providing those extra options.

[codenamev]

Some of these would be easier than others, but here are a few features I would love to see:

• Undo multiples (maybe given a timestamp/range)
• Chained audits (thinking some kind of simulated linked-list), that could allow you to undo related side-affects from changes.
• Rails view helpers to preview diff/changes of audit(s)

[hernanat]

@codenamev

Undo multiples (maybe given a timestamp/range)
Chained audits (thinking some kind of simulated linked-list), that could allow you to undo related side-affects from changes.

These are actually part of a feature I am working on right now.

@tbrisker

I definitely agree that we should drop support for Rails 4.x / Ruby < 2.3. I would also like to see a full revisit of the test suite, as I have a slight fear we may be experiencing some false positives due to some quirks in how the tests are setup / are ran...but that may be wishful thinking :P

[krainboltgreene]

I am a user that prefers both UUID primary keys and also uses JSONB. I absolutely do not need helpers for that.

[krainboltgreene]

One awesome thing that would be a breaking change would be a move away from "custom audit model that inherit from audit" and a move to "tell us how to store this data, we literally don't care" adapter patterns with some built in one already (active record, elastic search, redis for a few).

[darryn02]

@tbrisker Late to the party on this, but something I came across today that might be a breaking change worth introducing with v5 (if not too late) is a redefinition of the ascending and descending scopes on Audit. Currently, they are based on #version, but with the addition of .own_and_associated_audits, the versions may no longer share the same context since they could have different parent records. A more appropriate way to order that would accurately order own and associated audits might be to simply use #created_at. Happy to put together a PR for this if you'd like.

[douglaslise]

The removal of #version in scopes could be extended to optionally neither fill version field when creating an audit, because it currently needs an extra query only to get the previous version for incrementing it.
So I think we could make it optional.