| # |
Jul 20th 2017, 19:07 |
 jeremyharris |
that’s a good question, and one I can’t really answer well because I don’t manage my infrastructure - I use a PaaS. You bring up a good point about gracefully shutting them down, and it’s something I’m going to have to ask my provider about so I have a better understanding of how it works for me personally |
| # |
Jul 20th 2017, 19:02 |
mikesmoniker |
Worth noting I have supervisord to spin up new workers. I’m just focusing on attractive ways of bringing down stale ones. |
| # |
Jul 20th 2017, 19:01 |
mikesmoniker |
The latter is a bit of extra work for me because this app doesn’t have a redis/memcached/etc. backed cache right now. |
| # |
Jul 20th 2017, 19:00 |
mikesmoniker |
I’m curious what strategies its users have employed for cycling out the workers (the shell) during/after app deployments. Right now I’m not setting a max # of jobs/worker, but doing so would be one way. Also considered some kind of global cache kill switch in the worker loop (I think Laravel does this). I obviously don’t want to just `kill` them, but of course need a way to update those processes when I deploy new code. |
| # |
Jul 20th 2017, 18:58 |
jeremyharris |
I use it in my app, I might be able to help if he’s not around |
| # |
Jul 20th 2017, 18:58 |
mikesmoniker |
@savant If you have a minute sometime I’d love to ask you a couple questions about queuesadilla. |
| # |
Jul 20th 2017, 16:56 |
inoas |
admad jeremyharris here is the issue https://github.com/cakephp/cakephp/issues/10930 |
| # |
Jul 20th 2017, 16:47 |
inoas |
but prefix with/set to modify |
| # |
Jul 20th 2017, 16:47 |
inoas |
there could be readers or immutable objects too where we could omit get |
| # |
Jul 20th 2017, 16:47 |
inoas |
not sure how that can happen but for builders, aka objects where we set a lot of properties again and again, omitting set may be good |
| # |
Jul 20th 2017, 16:44 |
admad |
All the get/set prefixes make the code too verbose for my taste, wouldn't mind doing away with them were possible |
| # |
Jul 20th 2017, 16:38 |
inoas |
and get prefix for getting ... and for read/write objects use set + get prefix |
| # |
Jul 20th 2017, 16:38 |
inoas |
admad when splitting the magic setters/getters wouldn't it make sense for builder like objects to have the pure method name (without set prefix) for the setting? |
| # |
Jul 20th 2017, 16:37 |
inoas |
I take admad by his words - he doesn't put them into plush |
| # |
Jul 20th 2017, 16:33 |
hmic |
this is a no @inoas :p or do you read it differently? :d |
| # |
Jul 20th 2017, 16:32 |
admad |
I haven't been following the discussion |
| # |
Jul 20th 2017, 16:30 |
inoas |
(always a good barometer!) |
| # |
Jul 20th 2017, 16:30 |
inoas |
admad would you think it makes sense to open a ticket or will it just noise-annoy you? |
| # |
Jul 20th 2017, 16:29 |
inoas |
the builders would not "need" to offer getters, but they "could" |
| # |
Jul 20th 2017, 16:28 |
jeremyharris |
I don’t know. That might be appropriate in a separate discussion, with some pseudo code examples. I would like that for the ORM specifically, so we keep the pretty ->contain()->select() and if you want to get, use getContain, etc. |
| # |
Jul 20th 2017, 16:26 |
inoas |
what's the core teams stance on splitting stateful objects into builders (orm for instance) and read/write objects? https://github.com/cakephp/cakephp/pull/10887#issuecomment-316465007 |
| # |
Jul 20th 2017, 16:26 |
inoas |
but its more a proof of concept |
| # |
Jul 20th 2017, 16:25 |
inoas |
yes avoiding duplicate code is good also the validator already got unit tests |
| # |
Jul 20th 2017, 16:22 |
jeremyharris |
I may fork and play with it at some point, don’t have time right now though. maybe next week |
| # |
Jul 20th 2017, 16:22 |
jeremyharris |
one of the big reasons to use it would be to avoid a bunch of duplicate code |
| # |
Jul 20th 2017, 16:21 |
jeremyharris |
remember, it just validates arrays, which is all these options are |
| # |
Jul 20th 2017, 16:21 |
jeremyharris |
I think some of those problems could be solved with the existing validator - it can do coexistence as well as nested |
| # |
Jul 20th 2017, 16:21 |
jeremyharris |
:slightly_smiling_face: |
| # |
Jul 20th 2017, 16:20 |
inoas |
but it was a nice exertice into spl autoload, interfaces, builders, factories for me :) |
| # |
Jul 20th 2017, 16:20 |
inoas |
I have answered here https://gist.github.com/inoas/5d71c67f1714fc941a3e93bb408d1b7a |
| # |
Jul 20th 2017, 16:15 |
inoas |
right now it has some ugly hacks inside (VoidReturnType but also validationErrors passed as a reference) |
| # |
Jul 20th 2017, 16:14 |
inoas |
and it is very little code to declare the schema and to use the builder |
| # |
Jul 20th 2017, 16:13 |
inoas |
and auto completion on the opt() methods IF you declare the functions (else it uses __get()) |
| # |
Jul 20th 2017, 16:13 |
inoas |
schema |
| # |
Jul 20th 2017, 16:13 |
inoas |
this style allows auto completion by IDEs for types in the schmea |
| # |
Jul 20th 2017, 16:13 |
inoas |
I am not sure what would happen to nesting |
| # |
Jul 20th 2017, 16:13 |
jeremyharris |
but yeah, I think this style is a good compromise |
| # |
Jul 20th 2017, 16:12 |
jeremyharris |
I think just extending the validator and comparing $this->_fields (which are all defined validator fields aka option keys) to the keys in the data might work |
| # |
Jul 20th 2017, 16:12 |
inoas |
well "works" as in you can see things ;) |
| # |
Jul 20th 2017, 16:12 |
inoas |
if you pull that and just run OptionsBuilderTest.php in some browser/console it already works |
| # |
Jul 20th 2017, 16:12 |
inoas |
but yes I read that and to look in the console io |