cms
cms copied to clipboard
statamic
Compability for EloquentQueryBuilder
Just noticed this will be needed as part of the Eloquent package models PR seeing as we inherit from this class
~~Edit: moved to draft status as we'll need to support where nested and arrays~~
This should now be complete with everything needed for the Eloquent all models PR
@jasonvarga I'm struggling to figure out where to add @blueprint as an option for collection templates, since it's a lot more difficult to manually change when storing collections in the database.
@FrittenKeeZ We'd need to adjust the fieldtype used to select a template on the collection edit page to either allow text input so you can type @blueprint, or somehow add the @blueprint option. https://github.com/statamic/cms/blob/b7de86426e777ac44e1baba35b9b7869ea13b2a7/src/Http/Controllers/CP/Collections/CollectionsController.php#L427-L432
But that doesn't seem relevant to this PR.
@jasonvarga yeah I kinda tunnel visioned and wrote it here, before I realized it's not strictly related to Eloquent.
Having @blueprint as a selectable option would be ideal imo, since it's tightly bound to specific logic anyway.
@ryanmitchell for some reason bindings don't work when using the Eloquent contract as type hint, which makes absolutely no sense, so it should just be reverted to the actual class instead.
Statamic\Query\EloquentQueryBuilder::__construct(): Argument #1 ($builder) must be of type Illuminate\Contracts\Database\Eloquent\Builder, Illuminate\Database\Eloquent\Builder given, called in /Users/FSA/Projects/statamic/eloquent-driver/src/ServiceProvider.php on line 188
PR: https://github.com/ryanmitchell/cms/pull/3
I've been doing a bit of work on the eloquent driver over this week and it strikes me that this class might be better being bundled as part of that, as it allows for changes to be made alongside the driver requirements rather than needing to sync releases. What do you feel the benefit is of keeping it as part of core?
Thanks for the suggestion. I've pushed an update with that, which allows toSql, dd and count to be removed.
However, when/unless/tap need to stay as otherwise the subquery gets an instance of illuminate's builder, not statamics, which means that the where clauses etc dont pass through the extra logic required.
However, when/unless/tap need to stay as otherwise the subquery gets an instance of illuminate's builder, not statamics, which means that the where clauses etc dont pass through the extra logic required.
Cool, my bad. 👍