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

[NFR]: Registering custom expressions in PHQL Dialects like PostgreSQL @@ Expression #14954

Closed
tztztztz opened this issue Apr 20, 2020 · 3 comments
Labels
new feature request Planned Feature or New Feature Request

Comments

@tztztztz
Copy link
Sponsor Contributor

tztztztz commented Apr 20, 2020

Is your feature request related to a problem? Please describe.

I MUST use this kind of condition in PHQL:

to_tsvector('English', cast(client_data_original as TEXT)) @@ plainto_tsquery('English', ':cdo_ftxt:')

There are two problems:

  1. Phalcon doesn't recognize parameters in functions, so I can't use

plainto_tsquery('English', ':cdo_ftxt:')

I need to set explicit value without parametrizing it, like this:

plainto_tsquery('English', 'John Smith')

  1. Second more serious problem is, that PHQL doesn't recognize @@ expression, instead I can use function ts_match_vq, but after that, PostgreSQL is not using Fulltext index like it is using with @@ expression, so I really need PHQL to recognize @@ expression.

How can I modify PostgreSQL dialect in Phalcon source code to recognize such expressions?

Describe the solution you'd like
It would be ideal if we have way to register custom expressions to any dialect in similar way to register functions via registerCustomFunction method.

For example in PostgreSQL there are many very useful expressions to work with jsonb data type like: "|&>", "@>", "#>" etc. Currently I can't use them and it hurts.

Fixing those two problem would level up Phalcon ORM to higher level.

@tztztztz tztztztz added the new feature request Planned Feature or New Feature Request label Apr 20, 2020
@tztztztz
Copy link
Sponsor Contributor Author

Another suggestion is to allow adding conditions with "native" mark, so it is not processed by PHQL, but left as it is.

I think it would be much simpler solution to implement / code.

Something like:

$builder->andWhereNative($condition, $bindParams, $bindTypes);

In that case condition and binding are not processed by PHQL but left for final PDO execution, with binds merged with PHQL binds.

@tztztztz
Copy link
Sponsor Contributor Author

@niden
Copy link
Sponsor Member

niden commented Apr 23, 2020

Tracked in #14608

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature request Planned Feature or New Feature Request
Projects
None yet
Development

No branches or pull requests

2 participants