At the time we thought about it being a breaking change, but it would only be a breaking change if we called pluck() on arrays.
Adding the condition that we only call the pluck() in case the options are a query builder (the field wouldn't work previously in case it was), we call the pluck() on that builder similar to other relationships.
AFTER - What is happening after this PR?
Developer can now return a builder instance from the options callback like he does in other relationship fields.
HOW
How did you achieve that, in technical terms?
Check options before calling pluck on them. Only call pluck if they are a query builder.
Is it a breaking change?
No.
How can we test the before & after?
// this will fail on main branch and will work in this branch.
'options' => function($query) {
return $query;
},
// this will work on main and in this branch (previous behavior)
'options' => function($query) {
return $query->pluck('attribute','id');
},
WHY
BEFORE - What was wrong? What was happening before this PR?
Discussed in https://github.com/Laravel-Backpack/CRUD/issues/3455
At the time we thought about it being a breaking change, but it would only be a breaking change if we called
pluck()
on arrays.Adding the condition that we only call the
pluck()
in case the options are aquery builder
(the field wouldn't work previously in case it was), we call thepluck()
on that builder similar to other relationships.AFTER - What is happening after this PR?
Developer can now return a builder instance from the options callback like he does in other relationship fields.
HOW
How did you achieve that, in technical terms?
Check options before calling pluck on them. Only call pluck if they are a query builder.
Is it a breaking change?
No.
How can we test the before & after?