| # |
Mar 26th 2019, 16:10 |
 devito |
``` // Only all fields from the articles table including // a calculated slug field. $query = $articlesTable->find(); $query ->select(['slug' => $query->func()->concat(['title' => 'identifier', '-', 'id' => 'identifier'])]) ->select($articlesTable); // Select all fields from articles ``` |
| # |
Mar 26th 2019, 16:08 |
devito |
https://book.cakephp.org/3.0/en/orm/query-builder.html#selecting-specific-fields |
| # |
Mar 26th 2019, 16:05 |
devito |
sure 1 sec |
| # |
Mar 26th 2019, 16:04 |
neon1024 |
Can you link us to the part in the docs? Or share the code here? |
| # |
Mar 26th 2019, 16:04 |
neon1024 |
A closure? |
| # |
Mar 26th 2019, 16:03 |
devito |
in the docs theres an additional select method that has the table object passed through to it |
| # |
Mar 26th 2019, 16:03 |
devito |
yes |
| # |
Mar 26th 2019, 16:02 |
neon1024 |
“Creating a column” do you mean a calculated select field? |
| # |
Mar 26th 2019, 16:01 |
devito |
i am trying with creating the col in the select than just writing a where clause and i get column doesnt exist |
| # |
Mar 26th 2019, 16:00 |
neon1024 |
`$this->Site->nukeFrom($orbit, $toBeSure);` |
| # |
Mar 26th 2019, 16:00 |
devito |
eate a calculated column, do i need to pass in the query object to the select function so that the where conditions can have access to that new column? |
| # |
Mar 26th 2019, 15:49 |
josbeir |
$this->Cookie->delete('hello'); ? |
| # |
Mar 26th 2019, 15:42 |
steinkel |
https://github.com/CakeDC/users-example this one for a demo using CakeDC/Users |
| # |
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 |