-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add Logging #1291
Add Logging #1291
Conversation
payload = { serializer: serializer, adapter: adapter } | ||
ActiveSupport::Notifications.instrument(event_name, payload) do | ||
block.call | ||
end |
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.
did you need to use the &block
form? I think you should be able to remove the method argument and replace block.call with yield
(which is faster and saves object creation
we should also freeze the string here or reduce object allocations on what would be frequently called method, even if the notifications are turned off.
otherwise, 💯
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.
Thanks, I made these changes 👍
🎆 😻 yay.. plz see comments re: existing logger |
@bf4 thanks for the review, I made some changes. I prefer keep the commits for now when it is ok I squash these. |
@bf4 I answered each of your comments, they are under the "Show outdated diff" link, since the code changed. I waiting for your feedback ❤️ |
Generates logging when renders a serializer.
- Use yield over block.call - Freeze the event name string
* Keep only the `ActiveModel::Serializer.logger` to follow the same public API we have for example to config, like `ActiveModel::Serializer.config.adapter` and remove the `ActiveModelSerializers.logger` API. * Define the logger on the load of the AMS, following the Rails convention on Railties [1], [2] and [3]. This way on non Rails apps we have a default logger and on Rails apps we will use the `Rails.logger` the same way that Active Job do [4]. [1]: https://github.com/rails/rails/blob/2ad9afe4ff2c12d1a9e4a00d9009d040e636c9b0/activejob/lib/active_job/railtie.rb#L9-L11 [2]: https://github.com/rails/rails/blob/2ad9afe4ff2c12d1a9e4a00d9009d040e636c9b0/activerecord/lib/active_record/railtie.rb#L75-L77 [3]: https://github.com/rails/rails/blob/2ad9afe4ff2c12d1a9e4a00d9009d040e636c9b0/actionview/lib/action_view/railtie.rb#L19-L21 [4]: https://github.com/rails/rails/blob/2ad9afe4ff2c12d1a9e4a00d9009d040e636c9b0/activejob/lib/active_job/logging.rb#L10-L11
Move the definition of locals to inside the `info` block this way the code is executed only when the logger is called.
On the ActionController was using a adapter, and since the instrumentation is made on the SerializableResource we need to use the SerializableResource over the adapter directly. Otherwise the logger is not called on a Rails app. Use SerializableResource on the ActionController, since this is the main interface to create and call a serializer. Using always the SerializableResource we can keep the adapter code more easy to mantain since no Adapter will need to call the instrumentation, only the SerializableResource care about this.
@@ -31,6 +31,7 @@ def get_serializer(resource, options = {}) | |||
serializable_resource.serialization_scope_name = _serialization_scope | |||
begin | |||
serializable_resource.adapter | |||
serializable_resource |
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.
Could you explain why you made that change?
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.
seconded
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.
Take a look on this commit message maurogeorge@981c229
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.
Didn't clear it up for me
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.
The main purpose of this is to the instrumentation be called on the Rails controller, so if I remove, this test will be broken.
As you can see here the instrumentation is made on the ActiveModel::SerializableResource
what I think is the canonical way to use a serializer and as you can see we simply delegate the method to the adapter. If we call the adapter directly over use the ActiveModel::SerializableResource
we will need to change all adapters to call instrumentation on they methods serializable_hash
, as_json
and to_json
.
Keeping the ActiveModel::SerializableResource
we define this once and all adapter, including new ones, will have instrumentation.
Let me know if you have some doubt.
I'm generally 👍 with this PR. |
@@ -0,0 +1,12 @@ | |||
# Logging | |||
|
|||
If we are using AMS on Rails app the `Rails.logger` will be used. |
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.
by default
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.
Also, document that the event is render.active_model_serializers
This PR mixes a desired feature with good code and tests with an architectural and behavior change this maintainer is very 👎 on. Please separate the two into two PRs so we can get the feature (logging notifications) into master. |
Also, please fix warnings
|
@bf4 I believe the warning fixes do not belong in this PR since it does not touch the file causing the warning. Those should probably have been corrected in the PR that deprecated |
Or am I missing something? |
If they were in there, yeah i must have missed them in a rebase B mobile phone
|
Thanks for the review guys, I will made the changes when working on the project again. |
@bf4 @beauby I rollback all changes related with When you guys have some time please review. I think we can remove the labels Thanks a lot guys |
@maurogeorge I think I'm good with this. i'll give a few hours for other team members to comment |
notify_active_support do | ||
adapter.to_json(*args) | ||
end | ||
end |
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.
call me crazy, but I think this might be a good use case for an around filter
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.
@NullVoxPopuli please don't take off a hold when the raised issues haven't been addressed |
@@ -0,0 +1,26 @@ | |||
module ActiveModel | |||
class Serializer | |||
module Logging |
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.
I'm 👎 on adding new namespaces to what I hope to become the legacy namespace, #1310
It either needs to be in lib/active_model_serializers.rb, in lib/active_model_serializers/logging.rb or have 2 👍 by other maintainers
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.
@bf4 are you saying everything should be switched to the new namespace before adding anything?
wouldn't that only matter depending on the order of merges? waiting on stuff like that causes needless delays, imo
but maybe I misunderstand? idk
I'm definitely interested in this for use by Skylight. The instrumentation part of this looks great. |
@maurogeorge can we scope this PR to just the notifications? + def notify_active_support
+ event_name = 'render.active_model_serializers'.freeze
+ payload = { serializer: serializer, adapter: adapter }
+ ActiveSupport::Notifications.instrument(event_name, payload) do
+ yield
+ end |
@bf4 why? I made the last change you ask. At #1291 (comment) you say we need 2 👍 to go on, I think we have theses on #1291 (comment) and #1291 (comment). If I am not wrong you concern is around the namespace right? I think we can go this way until we solve the namespace issue. |
notify_active_support do | ||
block.call | ||
end | ||
end |
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.
yeah, I think you're right. This doesn't add anything but complexity. Sorry for having you extra work. I meant it as a thought if it made sense.. and it's more indirection than helpful
Up for discussion.... I could close that pr and make it into this one I thought maybe you'd want to do more logging stuff here Really whatever makes you feel most appreciated. I wouldn't have couldn't have the 'follow up' pr without this one. B mobile phone
|
I will close this and help with the review of the new one. Thanks for the rebase and keep the reference ❤️ |
Hi guys,
I think today we do not logging nothing right? Based on this I started working on a logging using
ActiveSupport::Notifications
andActiveSupport::LogSubscriber
.The actual log output on this patch is:
This makes sense to you guys? If make sense I can continue working on it.