Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Tags: dshoemaker/graphiti

Tags

v1.2.44

Toggle v1.2.44's commit message
Fix paginate arity check

This was for backwards-compatibility with custom adapters not supporting
offset, but our adapters do so we never ran into the issue.

v1.2.43

Toggle v1.2.43's commit message
bump version

1.2.42

Toggle 1.2.42's commit message
Fix specs and rubocop issues

v1.2.41

Toggle v1.2.41's commit message
bump version

v1.2.40

Toggle v1.2.40's commit message
Don't blow up when missing/unexpected context

v1.2.39

Toggle v1.2.39's commit message
bump version

v1.2.38

Toggle v1.2.38's commit message
Ensure multiple extra_attrs without blocks work correctly

Two pieces of context needed:

First, there's a bunch of logic around serializer attributes:
subclassing resources, explicit serializers, defaults, overrides, etc.
And all of this gets dicey considering it all wraps and hacks an
external library, `jsonapi-serializable`.  So we're pretty dumb about
saying "any time we're doing something that can affect serialization,
re-configure everything".

Second, we recently accommodated the scenario where a parent resource
class guards an attribute, and a subclass removes that guard. The logic
added says "if this was previously guarded, remove the guard - as we're
adding the property again, the guard will get added again if it needs to
be".

These two scenarios conflicted. If you had two `extra_attribute` calls,
the second would cause the first to be re-applied as part of the
"reconfigure everything" approach. And when re-applied, we remove the
prior guard...expecting it to be added again as part of the idempotent
nature of the call.

This worked as expected if you passed a block, because you'd end up back
[here](https://github.com/graphiti-api/graphiti/blob/master/lib/graphiti/util/serializer_attributes.rb#L20).
But if you didn't pass a block, you'd end up [here](https://github.com/graphiti-api/graphiti/blob/master/lib/graphiti/util/serializer_attributes.rb#L24),
with the logic being "the only thing we need to do here is add the guard
back.

This was dumb! If you're going to do the "reconfigure everything"
approach, you need to ensure you're following the same codepath - not
this special codepath that was added. This had the adverse effect that
no guard was re-added (for extra attributes, the conditional [is added
in a different way](https://github.com/graphiti-api/graphiti/blob/master/lib/graphiti/extensions/extra_attribute.rb#L43) than a normal guard).

So the fix is to ensure we always follow the same codepath, which will
now correctly re-apply the guard. And added tests for the scenario where
multiple `extra_attributes` are added with and without blocks.

Finally, I'm not so sure about the wisdom of "reconfigure everything".
This was added 3 years ago as part of the major refactor that replaced
`jsonapi_suite` and became the `graphiti` we know and love today. It's
possible that the scenarios we were worried about are no longer
relevant, and this is more of a hindrance than a help. For now, simplest
fix.

v1.2.35

Toggle v1.2.35's commit message
Fixed Standard error

v1.2.34

Toggle v1.2.34's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Merge pull request graphiti-api#336 from chiliburger/add-filter-group

Added filter_group DSL:

v1.2.25

Toggle v1.2.25's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Merge pull request graphiti-api#273 from richmolj/master

bump version