# |
Oct 2nd 2016, 22:45 |
shealyw2 |
lazy |
# |
Oct 2nd 2016, 21:24 |
moose517 |
the only thing i've done today is hang some VFR flight maps up on my wall as decoration, and drink beer |
# |
Oct 2nd 2016, 21:24 |
moose517 |
LMAO |
# |
Oct 2nd 2016, 21:23 |
moose517 |
my goodness i'm sooo bored. but nothing at all sounds entertaining at all XD |
# |
Oct 2nd 2016, 20:13 |
moose517 |
*brrrrup* |
# |
Oct 2nd 2016, 17:32 |
hmic |
welcome! |
# |
Oct 2nd 2016, 17:07 |
michaelze |
hmic: Seems to work pretty well! Thanks again for the hint! |
# |
Oct 2nd 2016, 16:55 |
michaelze |
hmic: I'll give it a shot, thank you very much :) |
# |
Oct 2nd 2016, 16:55 |
hmic |
hope it helps. |
# |
Oct 2nd 2016, 16:54 |
hmic |
it's *meant* for things like that ;-) |
# |
Oct 2nd 2016, 16:54 |
hmic |
so your beforeFind event can easily decide on which query to do what |
# |
Oct 2nd 2016, 16:54 |
michaelze |
hmic: That's actually a very good idea... didn't think about using the $options array for that purpose... |
# |
Oct 2nd 2016, 16:53 |
hmic |
you can access this $options array from the query all the time... |
# |
Oct 2nd 2016, 16:53 |
hmic |
just do: $this->Table->find('all', ['optOut' => true]); |
# |
Oct 2nd 2016, 16:52 |
hmic |
*and* the information is kept with the query it belongs to all the time, so nothing can go wrong |
# |
Oct 2nd 2016, 16:52 |
hmic |
you dont need to function in the behavior to trigger an opt out in this case |
# |
Oct 2nd 2016, 16:51 |
hmic |
so why dont you add the information to opt out to the query itself? |
# |
Oct 2nd 2016, 16:51 |
michaelze |
hmic: Apparently there are no events fired when a query is created... I already checked that ;) |
# |
Oct 2nd 2016, 16:50 |
michaelze |
hmic: sorry for the long text, I hope I made my point clear ;) |
# |
Oct 2nd 2016, 16:50 |
michaelze |
...sure that that is the query I want to modify... |
# |
Oct 2nd 2016, 16:50 |
michaelze |
...I'm logged in as the superadmin or something). When I call the opt out method I store a boolean value in my behavior that gets queried in the beforeFind() method. The problem is, that the "next" beforeFind() call may not be the call that corresponds to the query I want the opt out to happen... So I was wondering whether it is possible to hook into the query creation because there I can be... |
# |
Oct 2nd 2016, 16:50 |
michaelze |
hmic: My use case is as follows: I have a special column in some of my tables that make a record belong to a certain tenant within my application (tenant_id). I created a behavior that, when attached, automatically adds the required filter to any query. I added another method to the behavior that allows me to opt out of this behavior in case I want to also get records for other tenants (e.g.... |
# |
Oct 2nd 2016, 16:47 |
hmic |
still, whats the usecase? |
# |
Oct 2nd 2016, 16:47 |
hmic |
so i'd inspect that code to see if events are fired, which would give you the opportunity to intervene quite easily |
# |
Oct 2nd 2016, 16:46 |
michaelze |
hmic: The query is created in the Table::query() method. Is that what you asked? |
# |
Oct 2nd 2016, 16:45 |
hmic |
and whats the usecase also? |
# |
Oct 2nd 2016, 16:45 |
hmic |
michaelze, do you know how and when a query is created? |
# |
Oct 2nd 2016, 16:45 |
michaelze |
Hi everyone! Is there a way to modify a query by a behavior the moment it is created instead of the moment that it is executed (beforeFind())? |
# |
Oct 2nd 2016, 16:34 |
michaelze |
lorb: one problem could be that your app is crashing so you won't be able to dump the result... But you could try with as much rows before it is failing. That should give you a pretty good sight into what's happending |
# |
Oct 2nd 2016, 16:32 |
michaelze |
lorb: I personally don't have a lot of experience on that field (especially not with php). But a quick google search revealed this stackoverflow question: http://stackoverflow.com/questions/880458/php-memory-profiling |
# |
Oct 2nd 2016, 16:31 |
lorb |
how would I best figure that out? |
# |
Oct 2nd 2016, 16:31 |
michaelze |
lorb: just an example |
# |
Oct 2nd 2016, 16:31 |
lorb |
I have turned of validation, and looking for pointers where else cake may require this much memory |
# |
Oct 2nd 2016, 16:31 |
michaelze |
lorb: well yeah, obviously. what I mean by this is which part of it... Is it generating a lot of caches of some sort that don't get cleaned up? |
# |
Oct 2nd 2016, 16:30 |
lorb |
well, cakephp is. obviously. running the data directly to mysql gets it done with no trouble |
# |
Oct 2nd 2016, 16:29 |
michaelze |
lorb: okay, that sounds like something else is taking up the majority :) |
# |
Oct 2nd 2016, 16:29 |
michaelze |
lorb: I would guess handling a lot of data is not a common task for a orm... |
# |
Oct 2nd 2016, 16:28 |
lorb |
the records are just a few numbers. the whole data is read from a csv file that has just 3MB |
# |
Oct 2nd 2016, 16:27 |
michaelze |
lorb: have you analyzed what actually takes up all the space? I mean how big is one of your "row" arrays, what else is there sitting around taking up space? |
# |
Oct 2nd 2016, 16:25 |
lorb |
yes, I'm rewriting the code atm to do that, but I don't see why that has to be necessary. 100k is not that much data |
# |
Oct 2nd 2016, 16:25 |
michaelze |
lorb: what about splitting the save operation up into junks? |