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

Tables aliases broken ? #308

Open
frtess opened this issue Apr 20, 2021 · 3 comments
Open

Tables aliases broken ? #308

frtess opened this issue Apr 20, 2021 · 3 comments

Comments

@frtess
Copy link

frtess commented Apr 20, 2021

Hi, I am taking over an old code base that needs updating. They were still using FluentPDO v.1.0.0. After updating to latest (2.2.1) I notice that all the aliases on tables mess up the smart joins. Is there a way to make this work or do I really have to use ->disableSmartJoin() on all queries that break ?
Ex:
$query = $this->_fpdo->from('key_competencies_post2019 k')->orderBy('k.posX,k.posY'); // returns error table posX does not exist
$query = $this->_fpdo->from('key_competencies_post2019 k')->disableSmartJoin()->orderBy('k.posX,k.posY'); // works

Also, I know you are working on a proper documentation for v3, but are there migration notes somewhere for the different version changes ?

Thanks!

@cbornhoft
Copy link
Member

cbornhoft commented Apr 20, 2021

Wow that's quite the version upgrade. At first glance, that query should still work as expected. There was great effort made to maintain full backwards compatibility in v2.

Let me look into this and see what I find!

@frtess
Copy link
Author

frtess commented Apr 20, 2021

Lol it is indeed. I played with it a bit more and whatever I use as alias (just k, or AS k), it will not work. Only way to make it work is to remove the alias before posX ans posY. I know they are not needed in this particular case, but they have a TON of queries with joins that actually do need the aliases.

@cbornhoft
Copy link
Member

cbornhoft commented Apr 21, 2021

Okay, I've figured out the source of the issue... it's odd to say the least.

Certain systems like MySQL allow nearly every character in the current charset to be included as part of table and field names (eg. the table \%&&,! is valid when wrapped in delimiters). Version 2 of fluent also tried to reflect that as best it could, so commas are now valid naming characters. See #209 for the exact changes.

With that in mind, the query in your example sees k.posX,k.posY as one single column because there's no space. Changing the above to

$this->_fpdo->from('key_competencies_post2019 k')
    ->orderBy('k.posX, k.posY');

removes the attempted join and the query is written as expected. So this isn't a bug in fluent per se, but I'll see what I can do so that it checks for commas when there is no explicit delimiter present in version 3.

TL;DR Make sure there are spaces between column references!

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

No branches or pull requests

2 participants