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

Overlapping IDs leads to confusing behaviour #120

Open
doconnor-clintel opened this issue Jul 23, 2021 · 0 comments
Open

Overlapping IDs leads to confusing behaviour #120

doconnor-clintel opened this issue Jul 23, 2021 · 0 comments

Comments

@doconnor-clintel
Copy link

Not sure if this is better here; or in another place like jsonapi-rb/jsonapi-renderer#34

When you have a similar data type, but it has been modelled as two separate things (for internal reasons you don't wish to inflict on API consumers); you may try to do something like:

    class SerializableFoo < ::JSONAPI::Serializable::Resource
       type "foobar"
       
       attributes :bizz, :buzz, :things_that_arent_id
       
    class SerializableBar < SerializableFoo
       type "foobar"

This works until you create two different records with the same ID and pass them off for serialization in the same payload - only the first record will be rendered.

The workaround is to define id:

    class SerializableFoo < ::JSONAPI::Serializable::Resource
       type "foobar"
       id { "foo-#{@object.id}" }
   
   
   class SerializableBar < SerializableFoo
       type "foobar"
       id { "bar-#{@object.id}" }

However; this is difficult to discover. IE: Where used with activerecord, 95% of the time this will be "fine" in production if you have different IDs, until you hit a rare conflict.

Consider:

  • Expanding the examples in the readme?
  • Emitting warnings if you push something onto the rendering stack that already exists and is different to the existing record or came from a different serializer?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant