Add support for json comment

[jfrancoist]

This PR adds support for JSON comment format. The current behaviour stays as default to avoid any breaking change.

To enable JSON support the gem needs to be configured during application initialisation.

ActiveRecord::Comments.configure do |config|
  config.enable_json_comment = true
end

Having JSON comments allows for easier parsing with readily available libs instead of using regex to extract comments.

[grosser]

hmm lots of complexity ... how about the commenter collects all the info and then merges all the hashes and then serializes them to json ... strings etc stay the same

[bquorning]

If you had just one commenter class, you could call it with a mix of strings and hashes – which would become a mess. Isn’t it better to have the logic separated, as suggested by the current PR?

[grosser]

if users decide to pass in strings and hashes it would be a bit messy, but still work + make the transition easier if users use hashes consistently then it would be the same ?

…

On Mon, Apr 6, 2020 at 7:12 AM Benjamin Quorning ***@***.***> wrote: If you had just one commenter class, you could call it with a mix of strings and hashes – which would become a mess. Isn’t it better to have the logic separated, as suggested by the current PR? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACYZ3QXUIB6YCB3ED4DBTRLHPLXANCNFSM4L2L73RA> .

[jfrancoist]

In general having one commenter that would merge both strings and hashes together might not be problem, if on the other end a "human" is reading the comments.

On the other end if some application needs to make use of the comments for some task/analysis, it would make it much more difficult to interpret scenarios such as:

SELECT * FROM Users /* foo:bar, hello:world {"foo":zoo","hello":goodbye"} */

By having a clear separation of concerns we make sure existing use-case is not broken and enabling JSON comment is configurable.

In my opinion there should be only one transition path which is to either switch from base commenter to JSON or vis-versa, having a mix of both might lead to confusion or a bad practice of having two different comment format within the same comment block.

The goal of this PR is mainly to provide a "safe" way for tools to parse comments without the need of complex REGEX.

[grosser]

if we are going down the "it needs to be either or" route:

• don't need a configurator, set with a cattr_accessor ?
• keep the collection the same (just array management) and then make the serialization different based on the flag / don't add multiple classes and instruction blocks