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

Adds tests and documentation for polymorphism #1420

Merged
merged 1 commit into from
Mar 15, 2016

Conversation

wolovim
Copy link
Contributor

@wolovim wolovim commented Jan 9, 2016

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.

@beauby
Copy link
Contributor

beauby commented Jan 9, 2016

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 polymorphic option does not exist.

@wolovim
Copy link
Contributor Author

wolovim commented Jan 9, 2016

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 polymorphic option, the payload is:

{
   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.

}
}
```

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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

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

Copy link
Contributor Author

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).

Copy link
Contributor

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.

Copy link
Member

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)

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@wolovim
Copy link
Contributor Author

wolovim commented Jan 18, 2016

Checking in; How does this look? Is there anything I can do?

@beauby
Copy link
Contributor

beauby commented Jan 18, 2016

@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.
Other than that, great job, I'll merge it soon unless somebody raises their voice.

```

If the instance of `Picture` belongs to a `Product`, an example payload might be:

Copy link
Member

Choose a reason for hiding this comment

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

Specify adapter

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Member

Choose a reason for hiding this comment

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

Consistent with adapter

@wolovim
Copy link
Contributor Author

wolovim commented Jan 18, 2016

Maybe this will answer multiple questions at once (cc/ @bf4):

I went back and double checked all the return values. On 0.10.0.rc3, an example payload for both default and json adapter is the following (regardless of polymorphic option):

{
   picture: {
      id: 1,
      title: "sdf",
      imageable: {
         id: 1,
         name: "Nerb Flerger"
      }
   }
}

With the json_api adapter (also regardless of polymorphic option):

{
   data: {
      id: "1",
      type: "pictures",
      attributes: {
         title: "sdf"
      },
      relationships: {
         imageable: {
            data: {
               id: "1",
               type: "employees"
            }
         }
      }
   }
}

On release 0.9.4, adapter documentation was lacking and I couldn't quickly figure out how to add other adapters, but default payloads without the option return:

{
   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"
         }
      }
   }
}

@bf4
Copy link
Member

bf4 commented Jan 18, 2016

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

On Jan 18, 2016, at 2:01 PM, Marc Garreau notifications@github.com wrote:

Maybe this will answer multiple questions at once (cc/ @bf4):

I went back and double checked all the return values. On 0.10.0.rc3, an example payload for both default and json adapter is the following (regardless of polymorphic option):

{
picture: {
id: 1,
title: "sdf",
imageable: {
id: 1,
name: "Nerb Flerger"
}
}
}
With the json_api adapter (also regardless of polymorphic option):

{
data: {
id: "1",
type: "pictures",
attributes: {
title: "sdf"
},
relationships: {
imageable: {
data: {
id: "1",
type: "employees"
}
}
}
}
}
On release 0.9.4, polymorphic documentation was lacking and I couldn't figure out how to add other adapters, but default payloads without the option return:

{
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"
}
}
}
}

Reply to this email directly or view it on GitHub.

@wolovim
Copy link
Contributor Author

wolovim commented Jan 18, 2016

@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
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 find this cache clear neceassry or it was just copied? It shouldn't be necessary

@wolovim
Copy link
Contributor Author

wolovim commented Jan 19, 2016

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.

@beauby
Copy link
Contributor

beauby commented Jan 20, 2016

@marcgarreau Could you give #1453 a try?


module ActiveModel
class Serializer
module Adapter
Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Member

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.

Copy link
Contributor

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.

@wolovim
Copy link
Contributor Author

wolovim commented Jan 20, 2016

@beauby nice work on #1453! i saw that joão picked it up, but if you still need help testing anything, I can get around to it this evening.

@beauby
Copy link
Contributor

beauby commented Jan 20, 2016

@marcgarreau Awesome, testing would be great, and if you have a bit of spare time, writing AMS tests for it would be "even awesomer"!

@wolovim
Copy link
Contributor Author

wolovim commented Jan 20, 2016

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

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).

Copy link
Contributor Author

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.

@beauby
Copy link
Contributor

beauby commented Jan 21, 2016

@marcgarreau Would you mind submitting a PR with your tests to my branch?

@wolovim
Copy link
Contributor Author

wolovim commented Jan 21, 2016

@beauby will do shortly! didn't make it back online last night.

@wolovim
Copy link
Contributor Author

wolovim commented Jan 28, 2016

@beauby @bf4 did we decide to change anything with the polymorphic option? If so, I'll update this. If not, is this PR ready to go?

@remear
Copy link
Member

remear commented Mar 15, 2016

What remains to be done here?

@wolovim
Copy link
Contributor Author

wolovim commented Mar 15, 2016

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

@remear
Copy link
Member

remear commented Mar 15, 2016

@remear
Copy link
Member

remear commented Mar 15, 2016

I think if you can address that comment and squash these commits I'm good with merging this.

@wolovim
Copy link
Contributor Author

wolovim commented Mar 15, 2016

Great @remear, thanks for the attention. Will get to it shortly.

@remear
Copy link
Member

remear commented Mar 15, 2016

@marcgarreau Before you squash, could you also add this to the CHANGELOG

@wolovim
Copy link
Contributor Author

wolovim commented Mar 15, 2016

Missed that comment prior to squashing @remear, will address.

@wolovim wolovim changed the title Adds documentation for polymorphism Adds tests and documentation for polymorphism Mar 15, 2016
@remear
Copy link
Member

remear commented Mar 15, 2016

Thanks, @marcgarreau!

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