| # |
Jul 11th 2017, 15:35 |
 rudy1976s |
I will try |
| # |
Jul 11th 2017, 15:35 |
rudy1976s |
I need to extract data without foreach it |
| # |
Jul 11th 2017, 15:35 |
jeremyharris |
resultsets are collections by default, so you can do things like $this->find()->combine() |
| # |
Jul 11th 2017, 15:35 |
rudy1976s |
ah cool thank you |
| # |
Jul 11th 2017, 15:35 |
jeremyharris |
hash is meant for arrays only. you should use collections instead |
| # |
Jul 11th 2017, 15:34 |
rudy1976s |
Cake\Utility\Hash::extract is able to return entity interfaces instead of arrays? |
| # |
Jul 11th 2017, 15:33 |
rudy1976s |
Hello |
| # |
Jul 11th 2017, 15:18 |
ericadeefox |
getting tons of "Session not active, could not store state" Facebook SDK errors in my tests after installing a new FB helper plugin. adding `session_start();` to the top of the tests doesn't really solve the issue, since now my `$this->session()` setters aren't working, rendering stuff like admin tests useless. anyone faced this and know the most efficient way to set the session for FB? |
| # |
Jul 11th 2017, 14:54 |
chris-andre |
Seems more reasonable to add it to .gitignore |
| # |
Jul 11th 2017, 14:51 |
chris-andre |
Is the lock file generated when `migrations migrate` is run? |
| # |
Jul 11th 2017, 14:48 |
jeremyharris |
@chris-andre I use `--no-lock` on prod as mine are built from scratch each time and are read-only at that point (couldn’t write the lock even if it wanted to) |
| # |
Jul 11th 2017, 14:45 |
ericadeefox |
2.x to 3.x upgrade is basically just rewriting the whole site. O.O it's already daunting haha |
| # |
Jul 11th 2017, 14:45 |
chris-andre |
`git pull` gives me error almost everytime because of modified `schema-dump-default.lock` |
| # |
Jul 11th 2017, 14:43 |
chris-andre |
Is `bin/cake migrations migrate --no-lock` recommended to use on prod. server? Was reading some about it here https://github.com/cakephp/migrations/issues/252#issuecomment-254080302 |
| # |
Jul 11th 2017, 14:42 |
admad |
but for 2.x to 3.x you are already gonna have to change a lot |
| # |
Jul 11th 2017, 14:42 |
admad |
if one is already using 3.x i wouldn't recommend wasting time updating the deprecated methods until 4.0. |
| # |
Jul 11th 2017, 14:41 |
jeremyharris |
I see your point though. the getter/setters are a lot of changes; but having to do ALL of those immediately is much more daunting than doing the other things first, imo |
| # |
Jul 11th 2017, 14:41 |
neothermic |
true |
| # |
Jul 11th 2017, 14:41 |
admad |
@neothermic sure, but no point changing to already deprecated methods and waste time fixing them again in future |
| # |
Jul 11th 2017, 14:40 |
jeremyharris |
I just found it’s generally easier to take small steps - also mentally getting rewarded is a benefit |
| # |
Jul 11th 2017, 14:40 |
neothermic |
@admad Hundreds of thousands of lines of code can't be changed in a night ;) |
| # |
Jul 11th 2017, 14:40 |
admad |
@jeremyharris why stay behind the curve when it's possible to get on top right now? |
| # |
Jul 11th 2017, 14:39 |
neothermic |
I'm possibly going to be using the shim plugin to go into 3.x, as there's otherwise too many changes to make, and then slowly change things to not need the shim |
| # |
Jul 11th 2017, 14:39 |
jeremyharris |
you don’t need to worry about those until 4.x though, right? |
| # |
Jul 11th 2017, 14:38 |
admad |
@neothermic i say directly form 2.x to 3.4, that way you wont have to waste time again changing things like request->param() to request->getParam() as former was deprecated |
| # |
Jul 11th 2017, 14:36 |
jeremyharris |
well consider 3.x trial by fire for writing your tests |
| # |
Jul 11th 2017, 14:36 |
neothermic |
There's many reasons why our 1.3 -> 2.x upgrade took ~3 months |
| # |
Jul 11th 2017, 14:36 |
jeremyharris |
:) |
| # |
Jul 11th 2017, 14:36 |
jeremyharris |
uh oh |
| # |
Jul 11th 2017, 14:36 |
neothermic |
`run your tests` yeaaaaahhhh... |
| # |
Jul 11th 2017, 14:36 |
jeremyharris |
you only have to read a small doc at a time, run your tests, move on |
| # |
Jul 11th 2017, 14:35 |
jeremyharris |
that’s what I did. most of the minor versions go really quick, but it ensures you don’t miss anything |
| # |
Jul 11th 2017, 14:35 |
neothermic |
so from 2.x to 3.0, and then up each 3.x to latest? |
| # |
Jul 11th 2017, 14:35 |
jeremyharris |
I recently upgraded a small to medium app from 2.6 to 3.4, minor at a time |
| # |
Jul 11th 2017, 14:34 |
jeremyharris |
probably best to go minor versions at a time. it’s a lot less to think about and the migration docs are pretty solid on them |
| # |
Jul 11th 2017, 14:34 |
neothermic |
Yeah, I'm just debating how far into 3.x I go from 2.x; I possibly wont' go right to 3.6 if there's depreciations (for 4.0) in it |
| # |
Jul 11th 2017, 14:33 |
jeremyharris |
yeah, much easier to fix the deprecations along the way. the 3.x change will be massive though, so plan time for it. well worth it after the fact |
| # |
Jul 11th 2017, 14:32 |
neothermic |
So I've got a cleaner upgrade path |
| # |
Jul 11th 2017, 14:32 |
neothermic |
but this is why I also want to get past 2.8 :slightly_smiling_face: |
| # |
Jul 11th 2017, 14:28 |
neothermic |
Yeah, the 2.x -> 3.x change is something we're going to have to tackle in our codebase at some point before 2.x is moonlighted |
| # |
Jul 11th 2017, 14:27 |
inoas |
there is no reason to change everything... the 2.x -> 3.x break and the middleware change is already a huge change alltogether |