FuelPHP Forums

Okay, I solved some problems myself, but I'm still expericencing the issue with find_by('slug', $slug) and find_by_slug($slug) where the latter method dumps the aformentioned

Fuel\Core\PhpErrorException [ Warning ]: array_key_exists() expects parameter 2 to be array, string given error.

Is it an ID10T/PEBKAC-error or an ORM-related error? Any help appreciated!

I guess you're pretty right. The code of Orm\Model doesn't seem to show a 'find_by' option. However, if you're trying to unify the APIs, how far is your progress? I wouldn't mind to work on this topic and to make the 'find_by*' APIs unified (as well as add 'min_*' and 'max_*' to Orm\Model, which are mentioned in a comment at the end of __callStatic ;) )

By now, after extensively using the ORM, I don't wanna miss its features any more. But before that, I, too, would have said "You need a Model_Crud". Everybody's got their favorites ;)

Anyway, I'm still stuck with find_by_*, in particular in my case: find_by_slug_or_major_id($slug-from-uri, $slug-from-uri). This does not return the expected result as the query I get is a simple find('first'):

SELECT `t0`.`name` AS `t0_c0`, `t0`.`slug` AS `t0_c1`, `t0`.`created_at`
AS `t0_c2`, `t0`.`updated_at` AS `t0_c3`, `t0`.`major_id` AS `t0_c4`
FROM `majors` AS `t0` ORDER BY `t0`.`major_id` ASC LIMIT 1

Looking at the source code of Orm\Model::__callStatic I see an option called 'or_where' created and passed to Orm\Model::find('first', $options). However, in Orm\Query::__construct() nothing is taking care of the 'or_where' option. Dirty hacking a

case 'or_where':
  $this->_parse_where_array($val, '', true);
  break;

into Orm\Query::__construct() didn't really solve the problem at all (there is still now WHERE ( `slug` = 'slug-from-uri' OR `major_id` = 'slug-from-uri') in the generated query.)

Now, if you take a look at the first query posted, you will see that there is absolutely no where on either 'slug' or 'major_id'. If I change the method call to 'find_by_slug_and_major_id' (just for illustration), I get the following query

SELECT `t0`.`name` AS `t0_c0`, `t0`.`slug` AS `t0_c1`, `t0`.`created_at`
AS `t0_c2`, `t0`.`updated_at` AS `t0_c3`, `t0`.`major_id` AS `t0_c4`
FROM `majors` AS `t0` WHERE (`t0`.`slug` = 'slug_from_uri') AND
(`t0`.`major_id` = 'slug-from-uri') ORDER BY `t0`.`major_id` ASC LIMIT 1

So this works, at least. Yet, if I'm not mistaken, then this looks weird anyway. Shouldn't the WHERE * ANDs be inside brackets?

Adding the ''case: 'or_where' '' mentioned above to Orm\Query::__construct() at least generates an imho properly bracketed query:

SELECT `t0`.`name` AS `t0_c0`, `t0`.`slug` AS `t0_c1`, `t0`.`created_at`
AS `t0_c2`, `t0`.`updated_at` AS `t0_c3`, `t0`.`major_id` AS `t0_c4`
FROM `majors` AS `t0` WHERE ((`t0`.`slug` = 'slug-from-uri') AND
(`t0`.`major_id` = 'slug-from-uri')) ORDER BY `t0`.`major_id` ASC LIMIT 1

But I'm anyway not getting the results I want. Am I working to illiberally, or is there are bug somewhere in the ORM package?

Looked into it a bit further.

I think not all methods defined in the Query class are available as options in the constructor, because they don't really make sense.

The or_where is a perfect example, a combination of where clauses with AND or OR (and possibly brackets) only work if it is possible to specify the correct order in which they are processed. Which is not a problem when you chain methods, but impossible to do when you process an array like it is done in the Query constructor.

Your dirty hack fixes it for your particular use case, but it will leave users with the impression that you can now use 'or_where' in the options array, which is only true up to a point.

And even then, the constructor loops over the options in the order in which they are defined.

_parse_where_array() supports nested arrays, so perhaps it would be better to inject:

'or' => array(...)

into the where array and have _parse_where_array() deal with it.

SELECT `t0`.`name` AS `t0_c0`, `t0`.`slug` AS `t0_c1`, `t0`.`created_at`
AS `t0_c2`, `t0`.`updated_at` AS `t0_c3`, `t0`.`major_id` AS `t0_c4`
FROM `majors` AS `t0` WHERE ((`t0`.`slug` = 'slug-from-uri') AND
(`t0`.`major_id` = 'slug-from-uri')) ORDER BY `t0`.`major_id` ASC LIMIT 1

This still adds an AND in between the two WHERE clauses, which is why you don't get the results you want.

I checked a git blame, and it looks like the person initially responsible for Model_Crud (and not particularly an ORM lover) added the "find_by" functionality to the Model, and from the looks of it didn't check at all if the query object supported it. So this has never worked since it was introduces early 2011... :-(

That's awesome. I just checked out orm/1.7/develop and running find_by_slug_or_id works just the way I wanted it to work :)

But Sorry to bug you again, but somehow your update made some part of the code work but broke others i.e., running find_by_slug('slug-from-uri') now runs the following query:

SELECT `t0`.`name` AS `t0_c0`, `t0`.`slug` AS `t0_c1`, `t0`.`created_at` AS `t0_c2`,
`t0`.`updated_at` AS `t0_c3`, `t0`.`major_id` AS `t0_c4`
FROM `majors` AS `t0`
WHERE `t0`.`slug` = 'slug-from-uri'
AND ()
ORDER BY `t0`.`major_id` ASC LIMIT 1

which returns a MySQL 1064 error (as there is the AND() inside).

Fixed!

I'm not often in your neck of the woods, but I keep it in mind... :-)