| # |
May 29th 2017, 14:13 |
 cleptric |
@spriz -> friendsofcake |
| # |
May 29th 2017, 14:12 |
spriz |
Any FoC/Crud maintainers around? :tada: |
| # |
May 29th 2017, 13:43 |
npm.i.sniggsnack |
+i'm |
| # |
May 29th 2017, 13:41 |
npm.i.sniggsnack |
@redvelvet thank you trying to fix this up |
| # |
May 29th 2017, 13:27 |
TVSET |
I'm an idiot ... there is no need to flatten the data ... :) |
| # |
May 29th 2017, 13:23 |
HenriqueMachado |
and this is the "follow" function: https://pastebin.com/6fWYwFiR |
| # |
May 29th 2017, 13:22 |
bernat |
npm, I'd try to put it in the model via custom finders or some filtering method, and called from the controller. Nothing in the view. |
| # |
May 29th 2017, 13:11 |
npm.i.sniggsnack |
if you guys would have a view with a list - but specific users should see specific things in that list - where would you filter the data? controller or view ? atm i'd go for the controller and give the filtered data to the view to have a minimum of "logic" in my view.. is that right? |
| # |
May 29th 2017, 13:08 |
chris-andre |
@hmic When I do update, Sessions.data is still the same. It did not change |
| # |
May 29th 2017, 13:06 |
HenriqueMachado |
Hello! What is wrog with my models? When i trie to save a "follow" a new user is added: https://pastebin.com/nvQzch2G |
| # |
May 29th 2017, 12:59 |
hmic |
thats the whole point of database sessions after all (well, you can have a simple *small* loadbalancer setup with multiple frontend webservers and a central (session) database too, but it's not a good thing to scale out further and usually not fast anyways. still you would keep the sessiondatabase server separated from your application database server in this kind of setup) |
| # |
May 29th 2017, 12:57 |
hmic |
all the data will be loaded from the database at each and every request! |
| # |
May 29th 2017, 12:57 |
hmic |
chris-andre: with database sessions you do not need to care at all! |
| # |
May 29th 2017, 12:55 |
slackebot |
bad approach? :P So, how would I flag it, and how shall I look for that flag? |
| # |
May 29th 2017, 12:55 |
chris-andre |
But okay. So critical data should be updated. Admin need to "find the session" of the logged in user if he's logged in, right? To do that I will need a join table. And to let the currently logged in user "know" that critical updates are made by admin, I have to flag it some way, and I thought SessionsUsers.flag_update (bool) could do that. And again, to make sure I don't miss that flag, I will have to query that table upon every request. |
| # |
May 29th 2017, 12:50 |
TVSET |
the print_r prints an empty array ... any idea on what I'm doing wrong? |
| # |
May 29th 2017, 12:50 |
chris-andre |
So if an admin changes a users first_name, you would care about updating. Thats not critical and can wait until next login. |
| # |
May 29th 2017, 12:50 |
TVSET |
I have a weird issue with CakePHP 3 Hash ... here's the pastebin: https://pastebin.com/RkZpyKqj |
| # |
May 29th 2017, 12:49 |
TVSET |
hello :) |
| # |
May 29th 2017, 12:49 |
inoas |
just put them on an SSD :p |
| # |
May 29th 2017, 12:49 |
chris-andre |
I use db sessions. |
| # |
May 29th 2017, 12:48 |
inoas |
if you need to query the database anyway, database sessions ftw |
| # |
May 29th 2017, 12:48 |
hmic |
if you use database sessions, it's just that. no need to care or worry |
| # |
May 29th 2017, 12:48 |
inoas |
if that is not ciritical, not updateing saves queries |
| # |
May 29th 2017, 12:48 |
inoas |
if it is critical that for instance is_active or is_admin are always up to date, then yes |
| # |
May 29th 2017, 12:47 |
inoas |
depends |
| # |
May 29th 2017, 12:47 |
chris-andre |
Okay. One thing first then: Do you agree that session data should match the current user data in db? |
| # |
May 29th 2017, 12:45 |
hmic |
point beeing: he should rather trigger an event to reload database data into the session, or go with database sessions from the start, which solves the problem in one go. i'd prefer memcache over sql sessions still, easy to invalidate on update and repopulate and way better suited for the task |
| # |
May 29th 2017, 12:45 |
chris-andre |
Hmm.. Brain is boiling now :P |
| # |
May 29th 2017, 12:44 |
dereuromark |
as long as it is safe ;) |
| # |
May 29th 2017, 12:44 |
hmic |
:p |
| # |
May 29th 2017, 12:44 |
dereuromark |
who are we to judge |
| # |
May 29th 2017, 12:43 |
hmic |
still, its a bad idea to do so. |
| # |
May 29th 2017, 12:43 |
dereuromark |
maybe he doesnt have to :slightly_smiling_face: |
| # |
May 29th 2017, 12:43 |
hmic |
you will not be able to scale *at all* with this approach |
| # |
May 29th 2017, 12:43 |
hmic |
chris-andre: this is a bad idea. very bad! |
| # |
May 29th 2017, 12:43 |
chris-andre |
I'm going back to the "original idea", using join table. The purpose is that the user sessions always shall be updated with currently saved data in database. |
| # |
May 29th 2017, 12:41 |
chris-andre |
Right. I will always take his advice ;) |
| # |
May 29th 2017, 12:41 |
inoas |
maybe there is something that fits your bill already - or something you can learn from |
| # |
May 29th 2017, 12:40 |
inoas |
also take a look at awesome cakephp |
| # |
May 29th 2017, 12:40 |
inoas |
just create real foreign key constraints and a join table if necessary |