Closed mrbatista closed 6 years ago
@mrbatista the new HTTP module has been landed into the development branch, also I needed to change your PR in order to also land into the development branch.
Unfortunately there are some conflicts, would you mind to resolve the conflicts by updating your PR to the newest HTTP module?
Thanks, once you send this patch I will publish version 2.2.0
@mrbatista actually where
object is a part of loopback filters, so if you will use LoobBackConfig with option filterOn
=== headers
it should be ok. I believe there is no reason to add another similar config option.
Best regards, Vitali.
@nedzvedz thanks for your comment which makes a lot of sense.
@mrbatista would you mind to verify if the firlterOn headers works for you?
So I can publish the new sdk version with the new http module support that Inreceived yesterday
@nedzvedz your statement is not correct. There are some methods like update, updateAll, destroy, destroyAll and count that support only where clause. See this for more details. @jonathan-casarrubias For this reason is necessary to manage this option
@jonathan-casarrubias please re-open this PR.
@mrbatista I have reviewed and you are correct, only filter objects are being sent through headers when using that option, would you mind just to fix the merge conflicts.
There are some changes related to the new HTTP module, once the conflicts are fixed I can deploy this patch.
Cheers Jon
What type of pull request are you creating?
How many unit test did you write for this pull request?
Write a reason if none (e.g just fixed a typo): Comply with type of
where
object for model where user not define a priori the type of proprerties. Without the fixwhere
object like:is converted to:
I have tested coerce without SDK builder and work correctly. See this for more info.
Please add a description for your pull request:
This PR allow user to decide if
where
object is added on headers or query string.