3.0 - Implement magic find methods on Cake\ORM\Table

[markstory]

The magic findByXXX & findAllByXXX methods currently available on Model are handy for doing simple queries as they expose a powerful and simple to use API.

It would be nice to have the same features available on the new Cake\ORM\Table class in 3.0.

Implementation suggestions

• The Table class already has a __call method, hook into that to provide this feature.
• Making queries on columns that don't exist should trigger an exception.
• Only support the AND an OR operators for now, much like in 2.x.

[ravage84]

Yep, a must have 👍
Also keeps migration easier...
And yes, doesn't have to beyond the current featuers.

[hiromi2424]

How about to extract to a behavior?
I have created magic method behavior that works more powerful than cake's one.
Like created/modified, I think convenience features are preferable to be extracted out when possible.

[markstory]

That could be possible, it will require that people opt-into magic finder methods though by adding the behavior. I've still not put much thought into how we can make adding common behaviors like timestamps more simple. I guess having base classes implement initialize() is one option.

Adding the magic finders in a behavior will probably require modifying how method maps are generated for behaviors as well. You might need to enable pattern matching again, as generating all the permutations for any given table would be too expensive.

[AD7six]

I too am in favor of extracting the logic rather than embedding it - it's convenient for some but not all users use it (plus it's functionality that users ask to extend/modify).

[AD7six]

On reflection I think, if implemented, this should be in the table class. That way it's simple to implement by rewriting:

$this->findXxxByYyy($value);

To:

$this->find('xxx', ['conditions' => ['yyy' => $value]]);

Which would permit using your own finders by defining which behavior-finder xxx maps to. Also avoids the need for any kind of preg_match looping to be able to know which behavior class to call - preventing adding this feature from slowing things down even when it's not in use.

[markstory]

That seems like a reasonable approach, and I like the decomposition into a basic find.

[markstory]

I'll take a crack at this.

[markstory]

Closing as the related pull request has been merged.