-
-
Notifications
You must be signed in to change notification settings - Fork 920
Add ExistsFilter #906
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
Add ExistsFilter #906
Conversation
Please add unit & functional tests |
@teohhanhui I let you do the rebase thing okay? |
@vincentchalamon @soyuka I think we should allow the query parameter key ("exists") to be changed, right? Similar to "order". |
@teohhanhui I'm not sure that's needed but I can add it. Let me know. |
It's harmless even if there's a boolean property named "exists", which is also nullable. We've already handled it safely. But we can test that in a Behat scenario. 😆 |
Can you be more specific I didn't get that 😆 Should I add a behat test for exists? |
* Provides test data. | ||
* | ||
* Provides 4 parameters: | ||
* - order parameter name |
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.
Outdated phpdoc.
@@ -22,7 +22,7 @@ | |||
* | |||
* @author Kévin Dunglas <dunglas@gmail.com> | |||
* | |||
* @ApiResource(attributes={"filters"={"my_dummy.search", "my_dummy.order", "my_dummy.date", "my_dummy.range", "my_dummy.boolean", "my_dummy.numeric"}}) | |||
* @ApiResource(attributes={"filters"={"my_dummy.search", "my_dummy.order", "my_dummy.date", "my_dummy.range", "my_dummy.boolean", "my_dummy.numeric", "my_dummy.exists"}}) |
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.
Can't we split this nicely into one line per filter (and sorted alphabetically)?
We do have Behat tests for all the filters, e.g. https://github.com/api-platform/core/blob/master/features/doctrine/order_filter.feature What I meant is, we can add a boolean "exists" property in the dummy resource, and enable the BooleanFilter for that property. It should not impact the functionality of the ExistsFilter, because it uses a different structure from the BooleanFilter for the query parameters. |
Okay adding that. |
@teohhanhui 👍 for changing |
@vincentchalamon doesn't a non-conflict test suffice? I understand the need to change the "order" key but for "exists" it seems overdone. |
bd738a7
to
e0c1dcb
Compare
did the modifications but I think travis has an issue when I do the push on your repository @teohhanhui |
I'd actually love to see |
@teohhanhui Sometimes you just want to name that "sort" though \o/ |
@soyuka 👍 |
e0c1dcb
to
c6f1768
Compare
Scenario: delete | ||
|
||
@createSchema | ||
Scenario: Get collection that does not exists |
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.
Grammar: does not exists
One moment. Let me rebase... |
c6f1768
to
fc2343e
Compare
Rebased. |
"maxItems": 0 | ||
}, | ||
"hydra:view": { | ||
"@id": {"pattern": "^/dummies\\?exists=[exists=0]"}, |
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.
I think it should be "^/dummies\\?exists[exists]=0"
, isn't it?
"minItems": 3 | ||
}, | ||
"hydra:view": { | ||
"@id": {"pattern": "^/dummies\\?exists=[exists=1]"}, |
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.
Should be "^/dummies\\?exists[exists]=1"
I guess
/** | ||
* @var bool | ||
* | ||
* @ORM\Column(type="boolean", nullable=true, name="existsd") |
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.
Typo on name? existsd
=> exists
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.
EXISTS is an SQL keyword. But we should probably use a name that doesn't look like a typo.
it_exists
? 🤣
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.
is_exist
should be more consistent, no?
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.
@teohhanhui you do or I do the 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.
@soyuka Do you think we should get another PR merged into 2.0 branch to make some of the other filters more strict in terms of which properties they can be applied to? I'd argue that it should not be considered a BC break, for example if the RangeFilter stopped working for boolean properties (lol) or if the SearchFilter stopped working with a numeric property (really really bad idea in the first place).
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.
Hmm, something that would prevent from doing a NumericFilter on boolean for example?
I think that would be great indeed, with nice error messages to guide the developer.
The test failures indicate some of the other filters are not as strict as they should be... |
It's just because I added that |
Yeah, and because of that we have to add the property in the tests for some other filters where |
Yeah anyway I've already fixed the tests, pushing in a few minutes |
Though here we could not add a SearchFilter on |
I would prefer to get rid of Behat completely and write a nice API testing package. But it will require to rewrite our whole test suite. |
OMG I'm so +1 on this... I started writing some api tests with nodejs (request+superagent - nice chaining ideas there), but it's lacking a few things to write clean and easy-to-write tests (ie mainly json-based feature management). I'm all in if you need help on writing the tests again, and if you want to brainstorm on how we get to test APIs better! |
"maxItems": 0 | ||
}, | ||
"hydra:view": { | ||
"@id": {"pattern": "^/dummies\\?dummyBoolean[exists]=0"}, |
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.
This json schema is not correctly constructed. You could put anything in the pattern, tests would still pass.
See #967
(Same goes bellow)
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.
Thanks!
910a951
to
3967d1f
Compare
@teohhanhui lmk if this is good to you we can merge it. |
@soyuka I think we still need another approval. 🤣 |
As you wish 😛 |
|
||
$field = $propertyParts['field']; | ||
|
||
if ($metadata->hasAssociation($field)) { |
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.
Can't we refacto that to avoid that complexity ?
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.
You mean to reduce the cyclomatic complexity?
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.
Look at my commit (made my changes in a separate commit), I refactored it a bit.
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.
Just a little comment, but LGTM
5f8a34f
to
a3f47ad
Compare
I'm now officially a git rebase master \o/ @Simperfit done what I could (removed 3 lines of code 😆 ). |
Thanks @soyuka! ^^ |
Just tested this, but it does not read the assocation properties when autowiring - is there any reason for this? Works fine when defining them by using the configuration |
@aggrosoft I'm not sure how autowiring should work with variable constructors but you can check how I make it work in the PR that adds Filter annotations. |
Shouldn't something like this make the autowiring work: |
Add ExistsFilter
@aggrosoft I think you've found a (very old, probably introduced in #242 😱) bug! Sorry for not noticing earlier. 🙈 🤣 (See the diff around here: https://github.com/api-platform/core/pull/242/files#diff-023fcb894b9b3ad337dee44f2ba0a53aR242 - coincidentally also line 242 🍀) |
Never mind. I don't find anything like that in older versions of Doctrine's code. So I think it's just been broken all this while... |
IS NULL / IS NOT NULL (field / single-valued association)
or
IS EMPTY / IS NOT EMPTY (collection-valued association)