-
Notifications
You must be signed in to change notification settings - Fork 1
Merge upstream 1.21.0 into our fork #9
base: master
Are you sure you want to change the base?
Conversation
…ized-attribs Exclude path params from attributes hash
It is very happy if we can write `Model.page(params[:page])` like Kaminari.
…-nil allow nil for page number parameter
Fix custom type comment to use TypeFactory
…-to-fix-empty-array-param-issue JsonApiClient#278 updating faraday to fix issue when param value is an empty array
…eate-and-update-resource allow to send fields and/or includes on create/update resource
JsonApiClient#292 JsonApiClient#254 making scopes unmodifiable
…arning Use mocha/minitest instead of mocha/mini_test on test_helper
…r-new-custom-connection-arguments Update arguments for custom connections run method in README
fixing readme to update test and coverage icon targets
it will fix behavior when relationships and links are passed as symbol keys
…-pagination-override-example JsonApiClient#291 import README - pagination override examples
…w-symbolized-relationship-key JsonApiClient#290 symbolize params keys on model initialize
…efault-to-changes JsonApiClient#303 optional add default to changes
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.
Let's do it.
I see up above the concerns about testing and rollout, do we have a plan for how we want to go about rolling this out or testing it? One app at a time in QA first? Is there meaningful traffic we can push to apps in QA to get good enough coverage to feel confident enough? Is our integration testing story better now (would RING cover this?)
use HashWithIndifferentAccess, instead of symbolize_keys
Add extra error classes to handle server errors.
@donovan-lampa I'll update it once more with the recent updates to the upstream - so the HashWithIndifferentAccess is also included. |
@corsonknowles @ldrbrandon @dpep @donovan-lampa @openbl @dalyons Please note that I created a new branch "upstream" in our fork which forks off of 3f36f74, which contans all the upstream changes since we created our fork with our own modifications. This makes it easier to see our actual diff: |
I'll create more PRs for the upstream to bring our changes in, e.g. the bang methods, to make our diff even smaller |
adding create!, update_attributes!, update! methods
@donovan-lampa @dpep @corsonknowles @ldrbrandon @openbl |
places where we use our own fork: |
do we still need to be bumping this, or should we focus on getting the remaining chime-service (and libraries?) onto the public version of the gem? |
at this point, we can just try to upgrade the dependent repos to the public version of https://github.com/search?q=org%3A1debit+1debit%2Fjson_api_client&type=code |
Allow Faraday dependency up to v2.0
yes, totally agree - we should not have forked this repository in the first place |
Do you still want to merge this? |
merging upstream/master @1.20.0 into our fork, so we can get rid of our private fork of this gem.
this also includes the changes which were pushed upstream to use HashWithIndifferentAccess
JsonApiClient#386
and
JsonApiClient#389