Skip to content
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

Do not TRIM() parentheses around partial indexes conditions #716

Conversation

PowerKiKi
Copy link
Contributor

Because PostgreSQL will return the expression with a lot of
parentheses we cannot TRIM() them easily. It is easier and more
correct to adapt to what PostgreSQL returns. That means the declaration
of partial indexes must be updated as follow:

Before:
options={"where": "other_id IS NULL"}

After:
options={"where": "(other_id IS NULL)"}

And fore more complexe conditions, that would be:
options={"where": "(((id IS NOT NULL) AND (other_id IS NULL)) AND (name IS NULL))"}

@doctrinebot
Copy link

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DBAL-1033

We use Jira to track the state of pull requests and the versions they got
included in.

@PowerKiKi PowerKiKi changed the title Do not TRIM() parentheses around partial indexe conditions Do not TRIM() parentheses around partial indexes conditions Nov 5, 2014
@deeky666
Copy link
Member

deeky666 commented Nov 5, 2014

Looks like partial index conditions could cause a lot of headaches for the comparator. Requiring the user to know how the underlying platform returns the condition while introspecting the schema is PITA :( Not mentioning portability...
This needs a functional test showing that the comparator does not detect differences for a partial index when comparing the "offline" and "online" index.

@PowerKiKi
Copy link
Contributor Author

You are right that it is PITA. I thought we could somehow show a warning/message with what is expected when using CLI tools. Maybe with the orm:validate-schema command ? But that would actually require creating a temp table in database to know the exact expected result...

As for portability I don't think it is such a big issue. Things in options are note quite expected to be portable anyway.

May I suggest to merge this PR as is, because the current implementation is flawed and should be fixed before being released to public ? And maybe in a second step introduce some sort of help for the expected syntax ?

(Also note that the Travis was already failing in previous, non-related commit, this PR is not failing)

@Ocramius
Copy link
Member

I think this makes sense, but a few notes here:

  • is a functional test case possible? Can it be factored in to prevent regressions?
  • can the current limitations be documented in the .rst docs?

@Ocramius Ocramius self-assigned this Nov 13, 2014
@PowerKiKi
Copy link
Contributor Author

fair points, I'll have a look at that ...

Because PostgreSQL will return the expression with a lot of
parentheses we cannot TRIM() them easily. It is easier and more
correct to adapt to what PostgreSQL returns. That means the declaration
of partial indexes must be updated as follow:

Before:
``options={"where": "other_id IS NULL"}``

After:
``options={"where": "(other_id IS NULL)"}``

And fore more complex conditions, that would be:
``options={"where": "(((id IS NOT NULL) AND (other_id IS NULL)) AND (name IS NULL))"}``
@PowerKiKi PowerKiKi force-pushed the bug-partial-indexes-with-multiple-conditions branch from dfd62b6 to 853850c Compare December 29, 2014 07:09
@PowerKiKi
Copy link
Contributor Author

Hey @Ocramius, I completed with functional tests, rebased on master and documented in doctrine/orm#1232.

IMHO it's ready to be merged.

@deeky666 deeky666 closed this in b17992b Jan 3, 2015
@deeky666
Copy link
Member

deeky666 commented Jan 3, 2015

Merged manually with some additional assertions (revealed the test case was wrong). @PowerKiKi thx!

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

Successfully merging this pull request may close these issues.

4 participants