# |
Jul 4th 2021, 20:52 |
me1367 |
Yea.. though we'll see... I hope it'll be a relatively small one though... Mainly considering that the amount of big changes in CakePHP 7.4 and 8.0 is not too big... |
# |
Jul 4th 2021, 20:49 |
kevin.pfeifer |
the fact that cake 5 will require php 8.0 will definitely be more cumbersome i think |
# |
Jul 4th 2021, 20:49 |
kevin.pfeifer |
well, at least the jump from 3.x to 4.x is not that bad ,:) |
# |
Jul 4th 2021, 20:45 |
me1367 |
Yea, though in all fairness... It's kinda my own fault for still not being on 4.x :^) Procastinating like a champ. |
# |
Jul 4th 2021, 20:44 |
kevin.pfeifer |
the fact that cakephp 2.0 had support till now tells you, that you got enough time to migrate |
# |
Jul 4th 2021, 20:44 |
kevin.pfeifer |
well sure, there is already a 5.0 branch here https://github.com/cakephp/cakephp/tree/5.0 But that doesn't mean, that its comming out next week and that cakephp 3 will be discarded in the next months |
# |
Jul 4th 2021, 20:39 |
me1367 |
I'm barely done migrating to CakePHP 4 and 5 is already on it's way :| FML |
# |
Jul 4th 2021, 12:36 |
ragnarog_online |
thank you |
# |
Jul 4th 2021, 11:35 |
slackebot2 |
out early because the association property isn't marked as dirty, then that functionality would be lost. |
# |
Jul 4th 2021, 11:35 |
ndm |
@ragnarog_online Whenever you patch an association property it will be marked as dirty, no matter whether the nested data structure has any changes. It's not a bug, that is the intended behavior so that it is ensured that the ORM saving logic will run on the nested data. There might for example be `beforeSave()` callbacks for the nested data that would modify it, resulting a difference that needs to be saved, if the ORM would bail |
# |
Jul 4th 2021, 09:01 |
ragnarog_online |
SaveStrategy = replace |
# |
Jul 4th 2021, 08:56 |
ragnarog_online |
hello, is this a bug? relations : SalesOrders hasMany SalesOrderBatches SalesOrderBatches hasMany SalesOrderDetails what makes sales_order_batches dirty? |
# |
Jul 3rd 2021, 13:40 |
dereuromark |
I had the same thought^^ |
# |
Jul 3rd 2021, 13:15 |
kevin.pfeifer |
but thanks anyway for the help :bow: |
# |
Jul 3rd 2021, 13:02 |
kevin.pfeifer |
yea, refactoring my whole search logic to the search plugin is on my list |
# |
Jul 3rd 2021, 13:02 |
admad |
especially using the filter collections https://github.com/FriendsOfCake/search/tree/master/docs#filter-collection-classes |
# |
Jul 3rd 2021, 13:01 |
admad |
might as well look into using foc/search since you are at it. It will make your code very clean. |
# |
Jul 3rd 2021, 13:00 |
kevin.pfeifer |
i will do that |
# |
Jul 3rd 2021, 13:00 |
admad |
remove *everything* related to the request :) |
# |
Jul 3rd 2021, 12:59 |
kevin.pfeifer |
but yes, i can remove the request type check |
# |
Jul 3rd 2021, 12:58 |
kevin.pfeifer |
well first it was all present in the controller and then i moved all that inside that finder method |
# |
Jul 3rd 2021, 12:57 |
admad |
why the hell are you even checking request type in there currently? :) |
# |
Jul 3rd 2021, 12:57 |
kevin.pfeifer |
:) |
# |
Jul 3rd 2021, 12:57 |
kevin.pfeifer |
seems logical |
# |
Jul 3rd 2021, 12:56 |
kevin.pfeifer |
:thinking_face: |
# |
Jul 3rd 2021, 12:56 |
admad |
exactly, why should the finder need anything else from the request? |
# |
Jul 3rd 2021, 12:55 |
kevin.pfeifer |
so then I don’t have the whole request object inside my finder and just use the params |
# |
Jul 3rd 2021, 12:55 |
admad |
then use `$options['search']` in your finder to read the search args |
# |
Jul 3rd 2021, 12:54 |
admad |
And the changes is pretty easy, all you have to do is `find('index', ['search' => $this->request->getQuery()])` |
# |
Jul 3rd 2021, 12:53 |
kevin.pfeifer |
alright, then I will change that. thx for the info :bow: |
# |
Jul 3rd 2021, 12:52 |
admad |
@kevin.pfeifer ORM should never know anything about the incoming request. |
# |
Jul 3rd 2021, 09:32 |
kevin.pfeifer |
i was just trying to clean up my controller index function and thought this was fine ^^ |
# |
Jul 3rd 2021, 09:28 |
kevin.pfeifer |
so I shouldn't get the query args through the request object, instead I should pass them via the options. |
# |
Jul 3rd 2021, 03:37 |
admad |
@kevin.pfeifer your code is bad given the fact that you are directly using the query instance inside it instead of passing the querystring args through finder options. |
# |
Jul 2nd 2021, 21:57 |
kevin.pfeifer |
and yes my app has no authentication/authorization till now :) |
# |
Jul 2nd 2021, 21:56 |
kevin.pfeifer |
I don't want to make it a competition but I think my custom finder doesn't look that much better :,) |
# |
Jul 2nd 2021, 21:54 |
tyler.adam.lazenby |
btw yes I know I need to use authorization. |
# |
Jul 2nd 2021, 21:53 |
slackebot2 |
$contactToList) { if ($contactToList->contact_id === $contact->id) { $contact->isPart = true; break; } } } if ($this->request->is('ajax')) { $this->response = $this->response->withDisabledCache(); return $this->response ->withType('application/json') |
# |
Jul 2nd 2021, 21:53 |
slackebot2 |
->withStringBody(json_encode($contacts)); } return $contacts; }``` |
# |
Jul 2nd 2021, 21:53 |
slackebot2 |
$contacts = $this->Authorization->applyScope($contacts, 'index'); $contactToLists = $this->Contacts->ContactToLists->find() ->where(['contact_list_id' => $contact_list_id]); /** @var \App\Model\Entity\Contact $contact */ foreach ($contacts as $contact) { $contact->isPart = false; /** @var \App\Model\Entity\ContactToList $contactToList */ foreach ($contactToLists as |
# |
Jul 2nd 2021, 21:53 |
slackebot2 |
$contacts = $this->Contacts->find(); $contacts = $contacts->where([ 'OR' => [ "CONCAT_WS(' ', first_name, last_name) LIKE" => $contacts->func()->concat(['%', $param, '%']), 'first_name LIKE' => $contacts->func()->concat(['%', $param, '%']), 'last_name LIKE' => $contacts->func()->concat(['%', $param, '%']), ], ])->orderAsc('first_name'); |