Active
Project:
Drupal core
Version:
main
Component:
database system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 May 2012 at 13:49 UTC
Updated:
9 Oct 2019 at 01:24 UTC
Jump to comment: Most recent
The select extenders (PagerDefault, TableSort and SearchQuery) have an interesting design that could benefit from a re-thought. We should re-evaluate the database extender pattern and use something that is more sane.
@todo Write a proper issue summary.
Related issues
Comments
Comment #1
Crell commentedI discussed this a bit with chx at DrupalCamp Twin Cities. There's two closely related alternatives we can consider:
1) Instead of specifying a class for an extender, you instantiate an object yourself and pass it to $query->extend(). extend() then returns $this, not the extender object. SelectQuery (or whatever I renamed it to :-) ) then implements __call() for undefined methods and passes the call on to the first selector that has that method. On execute(), it also calls an extenderExecute() method on each extender (or something like that), effectively a junior hook, that lets extenders muck with things at the last moment. In practice I think execute() is the only integration point we need, so we don't need to allow overriding of all methods like in D7.
2) Same thing as above, basically, but extenders are a subclass of SelectQuery, which, thanks to a bizarre quirk of PHP, allows them direct access to the protected properties of the SelectQuery that they are assigned to rather than relying on the &getFields() et al methods.
I personally prefer option 1, as the latter seems like a hack. (It is, but it's a hack supported by PHP weirdness.) We would need to make sure that there's nothing lurking in contrib that's doing black magic we aren't accounting for, though.
Comment #8
andypost