Hi Tarique
Good example.
Let me give a real-life example. The largest known installation of Coppermine Picture Gallery (an Open Source project that I lead) has more than 3 million pictures and approx 100,000 users. As long as all the pictures and albums were public this was not a big problem. However Coppermine has a concept of user albums and private albums and password protected albums which can be or cannot be seen by public - the webmaster turned on the private albums feature and the hell broke loose as the queries started including criteria like "aid NOT IN (1,5,.......... long list of aids) and the looping checks were just too much.
I see the problem alright :-) I guess that in that situation you are limited by the complexity of the Aco tree. In my case I anticipate including business rules that minimise the list of Acos for a user. It should really be possible to limit a user to just half a dozen Acos or so in any given situation.
One way of doing this is to only extract Acos that are related to the Model that is being queried. This could be handled by naming conventions. I already do this in fact by filtering out the ":data" Acos. The idea was to avoid exactly that problem of overloading the query.
Coming to cakePHP perspective - I am currently wondering on how to exclude certain records from model->findAll* calls using the current ACL techniques. Actions which return or affect just one record will be no big deal atleast for some time but as the ACOs increase (in the above case 3 million +) performance will start to slow down even in those cases. That said I have to agree that example given by me is a rare one but at the same time a very plausible one.
Absolutely. I will argue that growth of Aco numbers can be dealt with though. Firstly by the method mentioned above and secondly by caching of the Aco data for the user.
This would mean no need to query Acos for findAll queries, other than at login (at which time you select all of their Acos and store them in a session or cache). After that it is just a matter of limiting the number of Acos included in an IN () clause to a reasonable number, possibly based on model type, or some other criteria.
Given that, I think that the design would scale well with both large numbers of users and records.
However I have never had to deal with a system that holds millions of records, so I may be wrong. It would be very interesting to find out.
Regards, Langdon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
