Closed agentphoenix closed 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?
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.
Thanks! Let me know if I can do anything to help.
Update your database module. It seems it's been fixed.
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;
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;
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:
I think the proper behavior should be:
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?