Ok i wrote some behaviour which should deal with the problem thou ill
need help with testing...
Any1 got idea for time consuming query, so i can run another one while
the first still executes?
Would be great if this query took about few seconds ;)
--~--~-~--~~~---~--~--
On Nov 26, 12:29 pm, Rob <[EMAIL PROTECTED]> wrote:
> I did use my own slightly modified version of TreeBehavior->recover()
> to repir tree and it was succesful, thou for 5000 acos it had done
> 500k queries to database and took about an hour to complete so i guess
> its not optimized at all.
>
I did use my own slightly modified version of TreeBehavior->recover()
to repir tree and it was succesful, thou for 5000 acos it had done
500k queries to database and took about an hour to complete so i guess
its not optimized at all.
Another thing is i cant afford repairing broken tree every time
You can also use TreeBehavior->recover() to recover a corrupted tree.
As for your LOCK TABLES I would look inside Tree Behavior itself.
On Nov 24, 8:23 am, Rob <[EMAIL PROTECTED]> wrote:
> i came up with solution to the issue described above, thou i need help
> with cake-wise implementation.
>
>
i came up with solution to the issue described above, thou i need help
with cake-wise implementation.
Solution includes using LOCK TABLES WRITE
http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html
i would like to include "LOCK" on acos and aros table to avoid
simultaneous queries before every
Helo i wonder if any1 had simillar problem to mine:
User added 2 photos in the same moment.
Photos model acts as Aco.
To acos table 2 rows were added:
id parent_id model foreign_key alias lft rght
506719 Photo 2366Photo.2366 86698670
506819 P
