Skip to content
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

Closed
wants to merge 12 commits into from
Closed

Add Logging #1291

wants to merge 12 commits into from

Conversation

maurogeorge
Copy link
Member

Hi guys,

I think today we do not logging nothing right? Based on this I started working on a logging using ActiveSupport::Notifications and ActiveSupport::LogSubscriber.

The actual log output on this patch is:

[AMS] Rendered PostSerializer with ActiveModel::Serializer::Adapter::JsonApi (5.72ms)

This makes sense to you guys? If make sense I can continue working on it.

payload = { serializer: serializer, adapter: adapter }
ActiveSupport::Notifications.instrument(event_name, payload) do
block.call
end
Copy link
Member

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, 💯

Copy link
Member Author

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 👍

@bf4
Copy link
Member

bf4 commented Oct 22, 2015

🎆 😻 yay.. plz see comments re: existing logger

@maurogeorge
Copy link
Member Author

@bf4 thanks for the review, I made some changes. I prefer keep the commits for now when it is ok I squash these.

@maurogeorge
Copy link
Member Author

@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
Copy link
Contributor

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seconded

Copy link
Member Author

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

Copy link
Member

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

Copy link
Member Author

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.

@beauby
Copy link
Contributor

beauby commented Oct 25, 2015

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by default

Copy link
Member

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

@bf4
Copy link
Member

bf4 commented Oct 25, 2015

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.

@bf4
Copy link
Member

bf4 commented Oct 25, 2015

Also, please fix warnings

Calling deprecated ArraySerializer in /home/travis/build/rails-api/active_model_serializers/test/collection_serializer_test.rb:10:in `new'. Please use CollectionSerializer

@beauby
Copy link
Contributor

beauby commented Oct 25, 2015

@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 ArraySerializer.

@beauby
Copy link
Contributor

beauby commented Oct 25, 2015

Or am I missing something?

@bf4
Copy link
Member

bf4 commented Oct 26, 2015

If they were in there, yeah i must have missed them in a rebase

B mobile phone

On Oct 25, 2015, at 6:03 PM, Lucas Hosseini notifications@github.com wrote:

@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 ArraySerializer.


Reply to this email directly or view it on GitHub.

@maurogeorge
Copy link
Member Author

Thanks for the review guys, I will made the changes when working on the project again.

@maurogeorge
Copy link
Member Author

@bf4 @beauby I made the changes as suggested, waiting for your review.
Thanks 😄

@maurogeorge
Copy link
Member Author

@bf4 @beauby I rollback all changes related with ActiveModel::Serializer.logger and keep the actual ActiveModelSerializers.logger since this namespace is a discussion on other thread.

When you guys have some time please review.

I think we can remove the labels Hold and Needs Team Discussion I think this is related with the namespace I am right?

Thanks a lot guys

@NullVoxPopuli
Copy link
Contributor

@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
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @bf4 I updated to use this 49c8f69. Personally I don't like, but I can live with it 😄

@bf4
Copy link
Member

bf4 commented Nov 5, 2015

@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
Copy link
Member

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

Copy link
Contributor

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

@wagenet
Copy link
Contributor

wagenet commented Nov 5, 2015

I'm definitely interested in this for use by Skylight. The instrumentation part of this looks great.

@bf4
Copy link
Member

bf4 commented Nov 5, 2015

@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

@maurogeorge
Copy link
Member Author

@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
Copy link
Member

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

@maurogeorge
Copy link
Member Author

@bf4 after the #1322 what is the idea? I stop working here and continue making revision on the new PR? If the Idea is to stop sending more code to this branch I think we can close this.

Thanks

@bf4
Copy link
Member

bf4 commented Nov 9, 2015

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

On Nov 9, 2015, at 5:26 AM, Mauro George notifications@github.com wrote:

@bf4 after the #1322 what is the idea? I stop working here and continue making revision on the new PR? If the Idea is to stop sending more code to this branch I think we can close this.

Thanks


Reply to this email directly or view it on GitHub.

@maurogeorge
Copy link
Member Author

I will close this and help with the review of the new one.

Thanks for the rebase and keep the reference ❤️

@maurogeorge maurogeorge closed this Nov 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants