jonathangeiger / kohana-jelly

See the link below for the most up-to-date code
https://github.com/creatoro/jelly
MIT License
146 stars 34 forks source link

Alias Problems #138

Closed agentphoenix closed 14 years ago

agentphoenix commented 14 years ago

Jelly Version: Unstable branch Kohana Version: 3.0.7

I posted on the support forums yesterday about an issue I was having (sorry for the double post here and there, just thought this would be a better place to address the bug) and I did some digging yesterday and today to see if I could find out what's happening. As far as I can see, this is an aliasing problem. Jelly is creating an alias for the model, but not using that alias for the fields, so my queries end up looking like:

nova_settings.setting_id AS id FROM nova_settings as settings

I think the proper behavior should be:

settings.setting_id AS id FROM nova_settings AS settings

If I run the second query in phpMyAdmin, it works like a charm, but the first query throws an error about the setting_id field not existing (which it does).

I was going to fork the code and work out a fix, but I'm not sure if the aliasing thing is the expected behavior or if there are other factors that need to be taken in to account when addressing this issue. Should the table be aliased like it is? If so, should that table alias be used in place of the prefixed table name in the SELECT clause?

agentphoenix commented 14 years ago

And found.

I stepped through the process piece by piece and realized that Jelly is using the proper alias, but when it gets passed to the database module, Kohana is appending the table prefix to the alias. In my case, the alias is settings and the full table is _novasettings hence the problem.

So the question from here is how to fix this issue. Any ideas?

jonathangeiger commented 14 years ago

Tough one. I'm inclined to say this is a bug with the database module. It should be honouring table aliases and not prefixing them. I'm going to do a bit more research and ensure it's prudent to file a bug with the core team.

EDIT

Yea, it appears the db module honours aliases when it's adding the prefix to the actual table in the FROM clause, but not for things like WHERE.

I'll file a bug and see the response. For now, this is an unstable branch and I'd recommend fixing your copy of the database module. The problematic lines are in Kohana_Database, 553 - 567.

I'm not entirely sure how you can workaround this. The most obvious solution is to simply not use prefixes and manually specify your tables with the prefixes.

agentphoenix commented 14 years ago

Thanks! Let me know if I can do anything to help.

jonathangeiger commented 14 years ago

Update your database module. It seems it's been fixed.

agentphoenix commented 14 years ago

That seems to have done the trick. Thanks for looking in to this, I really appreciate it.

I did notice when it started working that one thing didn't work like the old version (as I'm sure I'll find a lot of things like that). I used to chain the builder all the way through to my final output (in this case, an aliased field called value), but now that doesn't work. How would I do something like the below without having to loop through the entire object first?

Jelly::query('message')->key('welcome_header')->select()->value;
jonathangeiger commented 14 years ago

Just make sure you limit to 1.

Jelly::query('message')->key('welcome_header')->limit(1)->select()->value;

Or, if you've properly configured your name_key:

Jelly::query('message', 'welcome_header')->select()->value;