| # |
Mar 26th 2019, 15:41 |
 steinkel |
you can check this one too https://github.com/CakeDC/training-unit-tests |
| # |
Mar 26th 2019, 15:41 |
steinkel |
https://github.com/gothinkster/cakephp-realworld-example-app this one is a bit outdated |
| # |
Mar 26th 2019, 15:29 |
paul_83uk |
Whats the correct way to delete a cookie in cakephp 3.7? |
| # |
Mar 26th 2019, 15:28 |
dereuromark |
on patch Entity you shouldnt need to afaik, as there it comes from relations (and therefore the aliases) |
| # |
Mar 26th 2019, 15:28 |
dereuromark |
rogerpro: Yes, you need to call plugin classes using the dot syntax to find them |
| # |
Mar 26th 2019, 15:27 |
dereuromark |
Albatros: Check with hydration false, and compara the times. if thats it, then you know what the issue is. |
| # |
Mar 26th 2019, 15:24 |
rogerpro |
So far I found that `Cake\ORM\TableRegistry::get('Bars');` is building the table with magic, not using any plugin until called like `Cake\ORM\TableRegistry::get('PluginName.Bars');` |
| # |
Mar 26th 2019, 15:17 |
rogerpro |
My goal is to test associations, since `patchEntity()` is not saving an associated model. Does data in plugins always need `Plugin.Table` notation? |
| # |
Mar 26th 2019, 15:16 |
Albatros |
General problem is that we do not use "fields", we are getting the whole object, but however, the same result in the DB is 10x faster. This solution cause timeout after 30 secs (if we make debug directly after $query) |
| # |
Mar 26th 2019, 15:16 |
rogerpro |
Hi! I’m testing a plugin from the REPL console. I have 2 plugins with the same models. So from inside the REPL console, which plugin is Cake using when calling `Cake\ORM\TableRegistry::get('Bars');` ? |
| # |
Mar 26th 2019, 15:15 |
dereuromark |
maybe you can cut it down a bit, or use hdydrating(false) if hydration performance is an issue |
| # |
Mar 26th 2019, 15:14 |
dereuromark |
Albatros: sounds like you are pulling and hydrating a lot of data then. |
| # |
Mar 26th 2019, 15:14 |
ricksaccous |
ok |
| # |
Mar 26th 2019, 15:14 |
ricksaccous |
i seee, so querying 400 ids is not so bad |
| # |
Mar 26th 2019, 15:13 |
dereuromark |
you just need the IDs or sth, that is minimal, still kbs. |
| # |
Mar 26th 2019, 15:13 |
dereuromark |
? memory? if they are all separate tasks, there is no memory. |
| # |
Mar 26th 2019, 15:13 |
ricksaccous |
and loop through them to generate tasks? |
| # |
Mar 26th 2019, 15:13 |
dereuromark |
I do that here also for github/git operations. often it fails the first time, but then works on 2nd try. |
| # |
Mar 26th 2019, 15:13 |
ricksaccous |
might be bad to load 400 emails in memory though |
| # |
Mar 26th 2019, 15:12 |
dereuromark |
with API/gateway connections you should always plan for a single fail. |
| # |
Mar 26th 2019, 15:12 |
ricksaccous |
i see |
| # |
Mar 26th 2019, 15:12 |
dereuromark |
especially if you want to have properl logging and handling I suggested afterwards: " each indiviual fail can be auto-retried e.g. once." |
| # |
Mar 26th 2019, 15:12 |
ricksaccous |
you just sent all 400 as queue tasks to the queue. the workers process them invividually, until queue is empty. depending on how many workers, there could be a few sent in parallel. |
| # |
Mar 26th 2019, 15:11 |
dereuromark |
@ricksaccous I told you before :slightly_smiling_face: see above. |
| # |
Mar 26th 2019, 15:11 |
Albatros |
https://www.pastiebin.com/5c9a40ee68202 |
| # |
Mar 26th 2019, 15:11 |
ricksaccous |
@dereuromark would you recommend sending each individual email as a task or would you recommend having the task wade through all 400? |
| # |
Mar 26th 2019, 15:11 |
Albatros |
this is our "temp" solution |
| # |
Mar 26th 2019, 15:11 |
Albatros |
Indexes are in DB, and if we execute query in DB it is fast |
| # |
Mar 26th 2019, 15:11 |
dereuromark |
especially when you do order on fields like earliest_delivery_date |
| # |
Mar 26th 2019, 15:10 |
dereuromark |
make sure you have your indexes set. |
| # |
Mar 26th 2019, 15:10 |
Albatros |
https://www.pastiebin.com/5c9a40ee68202 |
| # |
Mar 26th 2019, 15:10 |
Albatros |
If @dereuromark is in CORE team, I have one question regarding performance. So, we have a Query where we are collection all orders (Super Admin). There is about 50 000 orders in the system. Now, after the user try to open orders/index site, the site is very slow -> here is our query |
| # |
Mar 26th 2019, 15:07 |
Albatros |
In every other community response on the question is much longer than in this channel (Respect :) ) |
| # |
Mar 26th 2019, 15:06 |
Albatros |
@dereuromark I will take a look your plugins (they are pretty updated :D ). I have already generated code with cake/bake but there are always additional things in combination with JS. There are no specific question, I wanted only to jump in into larger project :) |
| # |
Mar 26th 2019, 15:05 |
neon1024 |
Although Mark is in the core team :P |
| # |
Mar 26th 2019, 15:04 |
neon1024 |
Would be interesting as @dereuromark and myself have different approaches and styles |
| # |
Mar 26th 2019, 15:04 |
neon1024 |
If you could give us an example of something complex to validate we could answer that perhaps :slightly_smiling_face: |
| # |
Mar 26th 2019, 15:04 |
neon1024 |
If this is a theoretical question it will be hard to answer |
| # |
Mar 26th 2019, 15:03 |
neon1024 |
Plus you have cakephp/bake which will generate most ‘best practise’ boilerplate |
| # |
Mar 26th 2019, 15:03 |
dereuromark |
Some of the plugins going in that area will probably tell you a lot. |
| # |
Mar 26th 2019, 15:03 |
neon1024 |
Using elements is very straight forward |