-
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
Adds tests and documentation for polymorphism #1420
Conversation
Hi @marcgarreau, thanks for the PR! Could you specify which version of AMS this applies to? I believe in 0.10/master polymorphic associations are handled automatically, and the |
Didn't realize that! (I am using 0.10/master.) You're correct that it is not required, but it appears that it is still an option. With the {
picture: {
id: 1,
imageable: {
type: "product",
product: {
id: 3,
username: "Product 3"
}
}
}
} and without the option: {
picture: {
id: 1,
imageable: {
id: 3,
title: "Product 3"
}
}
} I don't think this is the place to debate the merits of each, but this would be nice stuff to know via README. I will update my changes to reflect this and get your feedback again. |
} | ||
} | ||
``` | ||
|
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.
💯 Should this doc change be in this file? Maybe in serializers
or layouts and rendering
? Just a thought, this might be the best spot, as well.
Is there a test for this behavior? Would be great to add.
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.
Busy week! Writing tests now, and will relocate these docs to a more appropriate location in next push.
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.
Awesome, thanks!
module Adapter | ||
class Json | ||
class PolymorphicTest < ActiveSupport::TestCase | ||
def setup |
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.
setup do
#...
end
removes the need to call super
in def setup
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 sorry, I don't know what you mean. This file pattern is taken directly from the other JSON adapter tests (i.e. https://github.com/rails-api/active_model_serializers/blob/master/test/adapter/json/belongs_to_test.rb).
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.
@marcgarreau Nothing wrong with the way you did it. It just happens that you could also use the block syntax as @bf4 suggested in order to avoid an explicit call to super
.
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.
@beauby nothing wrong, but we're taking advantage of activesupport::testcase which has this feature (just replace s/def setup/setup do
)
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 Agreed, I also favor it. I just wanted to make it clear to @marcgarreau that it was an improvement suggestion rather than error correction.
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.
Now I'm with you. Thanks for the hand-holding (and learning me something new)! Updated.
Checking in; How does this look? Is there anything I can do? |
@marcgarreau It looks good to me, but I'd like somebody with more experience (than me, cc @joaomdmoura) with polymorphic associations to chip in, to make sure the way we handle them actually makes sense. |
``` | ||
|
||
If the instance of `Picture` belongs to a `Product`, an example payload might be: | ||
|
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.
Specify adapter
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.
Oh you're right @bf4. For some reason, I thought the whole text was inside the Json
section of the adapters' doc.
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, it's really a serializer concern, eg serializer.associations that is presented consistently by adapter
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.
Consistent with adapter
Maybe this will answer multiple questions at once (cc/ @bf4): I went back and double checked all the return values. On {
picture: {
id: 1,
title: "sdf",
imageable: {
id: 1,
name: "Nerb Flerger"
}
}
} With the {
data: {
id: "1",
type: "pictures",
attributes: {
title: "sdf"
},
relationships: {
imageable: {
data: {
id: "1",
type: "employees"
}
}
}
}
} On release {
picture: {
id: 1,
title: "sdf",
imageable: {
id: 1,
name: "Nerb Flerger"
}
}
} and payloads with the option return: {
picture: {
id: 1,
title: "sdf",
imageable: {
type: 'employee',
employee: {
id: 1,
name: "Nerb Flerger"
}
}
}
} |
Awsome! 0.9 has no adapters... And both 0.8 and 0.9 use pre-1.0 json api which varied a bit B mobile phone
|
@bf4 I made the suggested change to the test and removed the example payload from the docs, because of the question about the payload key (i.e. how to identify which resource type you're receiving). That smells like an issue for more discussion and another PR. |
@picture.imageable = @employee | ||
|
||
@serialization = serializable(@picture, adapter: :json) | ||
ActionController::Base.cache_store.clear |
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 find this cache clear neceassry or it was just copied? It shouldn't be necessary
Consolidated tests into one and updated to the relative path. Happy to follow up with a has_many PR. This feels like a well-encapsulated explanation for this use-case (thanks to you guys' feedback), so I'd like to get this over the line first. As usual, happy to accommodate any other feedback. |
@marcgarreau Could you give #1453 a try? |
|
||
module ActiveModel | ||
class Serializer | ||
module Adapter |
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.
IMHO we should split this into different files under the adapters namespace for that sake of organization
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 for the feedback @joaomdmoura. My first implementation was split out like you suggested, but I followed @bf4's suggestion to combine these, which has a benefit of being able to compare the payloads side by side. If you'd like, I'll revert the changes. Let me know the final verdict.
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.
np, you can keep it as it is, it a non blocking comment for sure, I can talk with @bf4 later to know if there any other reason to keep it this way, but it's just a minor detail
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 hope to work with @remear to do some of these in cucumber so they're easier to compare, in general. I suggested one file since yhe differences are subtle '. I'd be for separate files if we were more consistent in test file organization
B mobile phone
On Jan 20, 2016, at 11:00 AM, João Moura notifications@github.com wrote:
In test/adapter/polymorphic_test.rb:
@@ -0,0 +1,72 @@
+require 'test_helper'
+
+module ActiveModel
- class Serializer
- module Adapter
IMHO we should split this into different files under the adapters namespace for that sake of organization—
Reply to this email directly or view it on GitHub.
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, the tests are currently a bloody mess. We really need to do something about it.
@marcgarreau Awesome, testing would be great, and if you have a bit of spare time, writing AMS tests for it would be "even awesomer"! |
@beauby: 👍 all: anything stopping this from getting over the line or are we considering adding scope? i'm happy to make follow up PR(s) for related work. |
@@ -74,6 +74,18 @@ def blog | |||
end | |||
``` | |||
|
|||
### Polymorphic Relationships | |||
|
|||
Polymorphic relationships are serialized by specifying the relationship, like any other association. For example: |
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.
If we merge #1453, this will have to change (to mention the polymorphic
option).
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.
Understood. Will wait for the word then and update docs/tests if necessary.
@marcgarreau Would you mind submitting a PR with your tests to my branch? |
@beauby will do shortly! didn't make it back online last night. |
What remains to be done here? |
@remear based on the label, maybe adding a little something to the changelog? The changes are just adding tests and bit of documentation, and I believe that's all good to go. Happy to accommodate if that's not the case. |
I think if you can address that comment and squash these commits I'm good with merging this. |
Great @remear, thanks for the attention. Will get to it shortly. |
@marcgarreau Before you squash, could you also add this to the CHANGELOG |
Missed that comment prior to squashing @remear, will address. |
Thanks, @marcgarreau! |
Adds tests and documentation for polymorphism
What's this PR do?
Adds baseline documentation for using polymorphic relationships within AMS.
EDIT: Added adapter tests, because there were none.
Any background context you want to provide?
I was unable to find any documentation within the docs about polymorphic relationships. Happy to move this documentation to another location or add to it if its inadequate.