Skip to content

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

Merged
merged 2 commits into from
Mar 20, 2017
Merged

Add ExistsFilter #906

merged 2 commits into from
Mar 20, 2017

Conversation

teohhanhui
Copy link
Contributor

@teohhanhui teohhanhui commented Jan 12, 2017

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes (thanks @soyuka!)
Fixed tickets N/A
License MIT
Doc PR TODO

IS NULL / IS NOT NULL (field / single-valued association)
or
IS EMPTY / IS NOT EMPTY (collection-valued association)

@vincentchalamon
Copy link
Contributor

Please add unit & functional tests

@soyuka
Copy link
Member

soyuka commented Feb 10, 2017

@teohhanhui I let you do the rebase thing okay?

@teohhanhui
Copy link
Contributor Author

@vincentchalamon @soyuka I think we should allow the query parameter key ("exists") to be changed, right? Similar to "order".

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

@teohhanhui I'm not sure that's needed but I can add it. Let me know.

@teohhanhui
Copy link
Contributor Author

teohhanhui commented Feb 13, 2017

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. 😆

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

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
Copy link
Contributor Author

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"}})
Copy link
Contributor Author

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)?

@teohhanhui
Copy link
Contributor Author

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.

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

Okay adding that.

@vincentchalamon
Copy link
Contributor

@teohhanhui 👍 for changing exists key. I also recommend a Behat test to check does not exist feature. /cc @soyuka

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

@vincentchalamon doesn't a non-conflict test suffice? I understand the need to change the "order" key but for "exists" it seems overdone.

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

did the modifications but I think travis has an issue when I do the push on your repository @teohhanhui

@teohhanhui
Copy link
Contributor Author

I'd actually love to see order_parameter_name deprecated if we can find out / make sure that there's no conflict.

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

@teohhanhui Sometimes you just want to name that "sort" though \o/

@vincentchalamon
Copy link
Contributor

@soyuka 👍
But I still recommend a does not exist test 😉

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

I've done that: https://github.com/api-platform/core/pull/906/files#diff-a6db6250a11c29a00faf3d4ae19a769fR10

Scenario: delete

@createSchema
Scenario: Get collection that does not exists
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grammar: does not exists

@teohhanhui
Copy link
Contributor Author

One moment. Let me rebase...

@teohhanhui
Copy link
Contributor Author

Rebased.

"maxItems": 0
},
"hydra:view": {
"@id": {"pattern": "^/dummies\\?exists=[exists=0]"},
Copy link
Contributor

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]"},
Copy link
Contributor

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")
Copy link
Contributor

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

Copy link
Contributor Author

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? 🤣

Copy link
Contributor

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?

Copy link
Member

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?

Copy link
Contributor Author

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).

Copy link
Member

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.

@teohhanhui
Copy link
Contributor Author

The test failures indicate some of the other filters are not as strict as they should be...

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

It's just because I added that exists property no?

@teohhanhui
Copy link
Contributor Author

It's just because I added that exists property no?

Yeah, and because of that we have to add the property in the tests for some other filters where $properties is null 😞

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

Yeah anyway I've already fixed the tests, pushing in a few minutes

@soyuka
Copy link
Member

soyuka commented Feb 13, 2017

Though here we could not add a SearchFilter on exists. What can we do about that?

@dunglas
Copy link
Member

dunglas commented Mar 3, 2017

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.

@soyuka
Copy link
Member

soyuka commented Mar 3, 2017

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"},
Copy link
Contributor

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@soyuka soyuka force-pushed the exists-filter branch 4 times, most recently from 910a951 to 3967d1f Compare March 12, 2017 11:13
@soyuka
Copy link
Member

soyuka commented Mar 13, 2017

@teohhanhui lmk if this is good to you we can merge it.

@teohhanhui
Copy link
Contributor Author

@soyuka I think we still need another approval. 🤣

@soyuka
Copy link
Member

soyuka commented Mar 13, 2017

As you wish 😛


$field = $propertyParts['field'];

if ($metadata->hasAssociation($field)) {
Copy link
Contributor

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 ?

Copy link
Contributor Author

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?

Copy link
Member

@soyuka soyuka Mar 16, 2017

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.

Copy link
Contributor

@Simperfit Simperfit left a 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

@soyuka soyuka force-pushed the exists-filter branch 2 times, most recently from 5f8a34f to a3f47ad Compare March 16, 2017 13:30
@soyuka
Copy link
Member

soyuka commented Mar 16, 2017

I'm now officially a git rebase master \o/ @Simperfit done what I could (removed 3 lines of code 😆 ).

@teohhanhui teohhanhui merged commit 8053c55 into api-platform:master Mar 20, 2017
@teohhanhui teohhanhui deleted the exists-filter branch March 20, 2017 06:55
@teohhanhui
Copy link
Contributor Author

Thanks @soyuka! ^^

@kingschnulli
Copy link

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

@soyuka
Copy link
Member

soyuka commented May 23, 2017

@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.

@kingschnulli
Copy link

Shouldn't something like this make the autowiring work:

kingschnulli@d29384b

hoangnd25 pushed a commit to hoangnd25/core that referenced this pull request Feb 23, 2018
@teohhanhui
Copy link
Contributor Author

@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 🍀)

@teohhanhui
Copy link
Contributor Author

teohhanhui commented Dec 19, 2018

Hmm... But I think at that time getFieldNames must have included the association names too, otherwise I wouldn't have written the code for that?!

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants