New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clog improvements #766
base: main
Are you sure you want to change the base?
Clog improvements #766
Conversation
I think we can include-by-default. NetAddr can be handled specially as Now, one idea I had different than you, I'm not sure if it's better or worse, and it's not mutually exclusive, was to support an array return from the block, so you could do this: Clog.emit('msg') do
[my_model, { my_custom_field: ... }]
end Also, supporting an abbreviated form when there are no custom fields: Clog.emit('msg') { my_model } By handling For There's still some use for in-hash special model handling, imagine, for example: Clog.emit("failing over") do
{ from_server: from_server, to_server: to_server }
end But, it's pretty rare. In the future, we may want to add a protocol to suppress the emission of dangerous fields that, for whatever reason, are not encrypted (like PII), or of those that are too expensive to emit. Or even has special renderings (a denser digest of a public key, for example) But I think there's a lot of time for that. |
Unrelatedly, I also go back and forth whether the block form I used for the values in I also have some terrible ideas about how to make Then the whole idea of not calling a block passed to |
2ff7966
to
52f6429
Compare
52f6429
to
42d1ad3
Compare
@fdr I have 6 separate commits based on your feedbacks. Can you take a look again? |
0ec834d
to
237da61
Compare
@fdr What do you think about the latest version? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get it in, at long last.
We redact encrypted and lengthy columns from the .inspect output in our models. It would be wisely to apply the same redaction to our clog metadata as well. Also, if the `Sequel::Model` is provided as metadata, the model automatically determines the key name from its table name and returns it with redacted values. `{ strand: strand.values }` can be abbreviated as `{ strand }`.
Sometimes, the model data is insufficient, and we may need to add extra fields to the clog's metadata. The new array metadata feature achieves this. When the metadata is an array, it parses each element sequentially. If the element is a Sequel::Model, it obtains its clog representation, similar to the previous commit. If the element is a hash, it merges with the intermediate hash. For example, `[strand, {field1: "a", field2: "b"}]` expands to `{strand: {id: 123, label: "start"}, field1: "a", field2: "b"}`.
237da61
to
52f23b5
Compare
Add a special clog representation for Sequel::Model
We redact encrypted and lengthy columns from the .inspect output in our models. It would be wisely to apply the same redaction to our clog metadata as well.
Also, if the
Sequel::Model
is provided as metadata, the model automatically determines the key name from its table name and returns it with redacted values.{ strand: strand.values }
can be abbreviated as{ strand }
.Allow to log additional fields with models in clog
Sometimes, the model data is insufficient, and we may need to add extra fields to the clog's metadata. The new array metadata feature achieves this.
When the metadata is an array, it parses each element sequentially. If the element is a Sequel::Model, it obtains its clog representation, similar to the previous commit. If the element is a hash, it merges with the intermediate hash.
For example,
[strand, {field1: "a", field2: "b"}]
expands to{strand: {id: 123, label: "start"}, field1: "a", field2: "b"}
.