| # |
Aug 28th 2019, 09:56 |
 dereuromark |
In 3.x it is nice that you have testing isolated inside this vendor package (vendor/bin/phpunit etc), while you can already work with it as demo inside the actual app. they dont interfere here in terms of testing. |
| # |
Aug 28th 2019, 09:55 |
dereuromark |
I usually start baking the skeleton and making sure the composer+autoload works already. Then I require it already in a project as vendor package. I have two open IDEs, project + plugin. Then I start developing the plugin with TDD, having (unit)tests for rapid prototyping right away. In Parallel I can easily confirm this also in real life app. Once all is nice, I push plugin code for travis. |
| # |
Aug 28th 2019, 09:52 |
alexdd55976 |
@kaliel @dereuromark intersting quesion.. would be interesting for me too |
| # |
Aug 28th 2019, 09:49 |
kaliel |
@dereuromark can i ask you what's your worflow when building a plugin ? Do you start a new dummy cakephp project, or do you build the plugin inside a live project ? |
| # |
Aug 28th 2019, 09:23 |
val |
It seems the simplest solution is to call `deleteAll` on dependent model as the first step |
| # |
Aug 28th 2019, 09:19 |
neon1024 |
@ricksaccous I sorted out my associated data marshaling issue. The answer was staring me in the face. It’s right in the docs, I just didn’t read properly. I have to add `Questions._joinData` to the `associated` key in `patchEntity` :face_palm: |
| # |
Aug 28th 2019, 09:19 |
dereuromark |
or you set a higher timeout limit, this way you have the nice user experience of having the option of undo a delete (like sending emails => abort) |
| # |
Aug 28th 2019, 09:18 |
dereuromark |
soft delete is just setting a flag, and then background takes care of it after a few seconds anyway. |
| # |
Aug 28th 2019, 09:18 |
dereuromark |
like soft-delete => queue hard delete |
| # |
Aug 28th 2019, 09:18 |
dereuromark |
PS: many would probably async offload that into a background (queue) task if it doesnt have to be all done in sync user interaction. |
| # |
Aug 28th 2019, 09:17 |
dereuromark |
you cant have it all including dependent record stuff. highly complex with all involved callback options. |
| # |
Aug 28th 2019, 09:16 |
dereuromark |
use deleteAll() and use manual cleanup if you need performance |
| # |
Aug 28th 2019, 09:16 |
dereuromark |
thats on purpose. |
| # |
Aug 28th 2019, 09:16 |
val |
I think there is performance problem in that `deleteMany`. It seems to execute many SQL statements instead of one like in `deleteAll`. |
| # |
Aug 28th 2019, 09:14 |
dereuromark |
And I recommend to always use the *ManyOrFail() ones to avoid silent failures. |
| # |
Aug 28th 2019, 09:14 |
dereuromark |
You could backport this deleteMany() into your code until 3.9 lands. |
| # |
Aug 28th 2019, 09:14 |
val |
'dependent' is already set to `true` in the association |
| # |
Aug 28th 2019, 09:14 |
neon1024 |
To me `deleteAll()` with dependent could be very dangerous |
| # |
Aug 28th 2019, 09:13 |
neon1024 |
Probably need to call `delete()` with `dependent` set in the association |
| # |
Aug 28th 2019, 09:12 |
dereuromark |
ah sry, that is available only in 3.9 and 4.0 ( https://github.com/cakephp/cakephp/blob/3.next/src/ORM/Table.php#L2388 ), I am thinking already too far ahead. |
| # |
Aug 28th 2019, 09:09 |
val |
I meant `Table::deleteAll()`. There is no`deleteMany()` in Table class. |
| # |
Aug 28th 2019, 09:08 |
dereuromark |
update"All"() are atomic (no callbacks) |
| # |
Aug 28th 2019, 09:08 |
dereuromark |
the Many are supposed to be the ones non atomic afaik |
| # |
Aug 28th 2019, 09:07 |
dereuromark |
isnt there deleteMany()? |
| # |
Aug 28th 2019, 09:06 |
val |
Hi, is it intended that `deleteAll()` in 3.x does not delete dependent records like in 2.x? |
| # |
Aug 28th 2019, 09:05 |
development |
Ok, thanks @dereuromark! |
| # |
Aug 28th 2019, 09:04 |
dereuromark |
you can remove it, sniffers would do that for you as well. same namespace doesnt need it. |
| # |
Aug 28th 2019, 08:58 |
development |
When I bake a new controller, it adds this to the top of my file: namespace App\Controller; use App\Controller\AppController; PhpStorm tells me the 'use' is unused. Is this some kind of double declaration and if so, can someone tell me why bake adds both of them and if I can remove it since PhpStorm says it is unused? |
| # |
Aug 28th 2019, 08:10 |
neon1024 |
Morning everyone :wave: |
| # |
Aug 28th 2019, 08:03 |
ndm |
PHP sucks at serving files either way, as the process has to run the whole time. |
| # |
Aug 28th 2019, 07:29 |
spriz |
but we also mostly handle batches of ~2-3 mb JPEGs and rather large dat/csv/txt files (50-100mb) |
| # |
Aug 28th 2019, 07:28 |
spriz |
I see - I thought actually streams always would more or less outperform strings in memory |
| # |
Aug 28th 2019, 07:27 |
spriz |
but that might be more of a PHP thing than a Cake thing anyway :slightly_smiling_face: |
| # |
Aug 28th 2019, 07:27 |
admad |
unless your file is very large not using streaming is more efficient i believe |
| # |
Aug 28th 2019, 07:26 |
spriz |
or `stream_get_contents()` for the matter |
| # |
Aug 28th 2019, 07:26 |
spriz |
I'm just thinking of poor newcomers to which the whole `stream` thing might be new. I see a lot of `file_get_contents` around still |
| # |
Aug 28th 2019, 07:25 |
spriz |
True, that's perfect for me as well :) |
| # |
Aug 28th 2019, 07:25 |
admad |
`$response->withBody(new Stream($fileStream))` is easy enough |
| # |
Aug 28th 2019, 07:24 |
spriz |
I guess there is some overhead of converting a `resource` to `StreamInterface` so it would be better if one could keep things in `StreamInterface` from the start - maybe that's the reasoning? |
| # |
Aug 28th 2019, 07:23 |
spriz |
Oh yeah, I remember expecting that initially |
| # |
Aug 28th 2019, 07:22 |
admad |
`withBody()` could have had a wider argument type which converted a resource instance into StreamInterface instance :P |