Thanks for taking the time to help. I am now attempting cache the ACL.
I get Uncaught exception 'Zend_Cache_Exception' with message 'Datas must be string or set automatic_serialization = true' ... When I set automatic_serialization I get: Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDO instances' ... I can't win :-) - Robert -----Original Message----- From: Jason Webster [mailto:[email protected]] Sent: 12 February 2009 17:29 To: Zend Framework - General Subject: Re: [fw-general] Optimising Zend_Acl On 12/02/2009 9:12 AM, Robert Castley wrote: > > I currently store a role_id in the user table. > i.e. User rwc has role_id 1 (1 = Admin, 2 = Manager, 3 = User etc.) > > Where/how do I cache the ACL so that each user that logs into the > system takes advantage of this. It is somewhat irrelevant if a particular user is is logged in or not, because regardless, all your roles are in the ACL, correct? > > Do I cache the result of $acl = new My_Acl()? How do I then query the > cache to find out if user rwc has access to the administration panel? What I originally intended was that you'd simply serialize and save to disk (or whatever) your entire ACL object, since, in your original post you were concerned about the number of queries to the database to build your ACL object, would save you those. Well, pseudo code says: if(cache has acl) { $acl = $cache->load('acl') } else { $acl = new My_Acl(); $cache->save('acl', $acl) } And if you make any changes to your ACL, simply invalidate the cached version. > -----Original Message----- > From: Jason Webster [mailto:[email protected]] > Sent: 12 February 2009 17:07 > To: Zend Framework - General > Subject: Re: [fw-general] Optimising Zend_Acl > > One potential option is caching the entire, constructed ACL object. > Simply invalidate the cache when any changes are made to ACL, and it > will be rebuilt on next request. > > I'm sure you don't need the nitty gritty implementation details. > > > On 12/02/2009 8:53 AM, Robert Castley wrote: >> Hi, >> >> Could someone help me out? >> >> I have Zend_Acl all up and running lovely, but further research shows >> that some projects serialize the data and store in a database. >> >> My ACL implementation already uses a database for storing roles, >> resources etc. but on each time I see my ACL these calls are made to >> the database and I am wondering how to slim this down. >> >> e.g. >> SELECT "acl_roles".* FROM "acl_roles" ORDER BY "role_id" DESC >> SELECT "acl_resources".* FROM "acl_resources" >> SELECT "acl_roles".*, "acl_resources".*, "acl_permissions".* FROM >> "acl_roles" INNER JOIN "acl_resources" INNER JOIN "acl_permissions" >> WHERE (acl_permissions.resource_uid = acl_resources.uid) AND >> (acl_roles.role_id = acl_permissions.role_id) >> SELECT "acl_roles".*, "users".* FROM "acl_roles" INNER JOIN "users" >> WHERE (users.username = "rwc") AND (users.role_id = acl_roles.role_id) >> >> Obviously if I have a page with a ACL call and then two further Ajax >> calls that populate the page that also do ACL calls I get the above >> SQL sequence x 3 ... not efficient. >> >> The way I am using ACL in my Application is like so: >> >> /** >> * Render Administration dialog >> * >> * @return void >> */ >> public function administrationAction() >> { >> if (!$this->_acl->isUserAllowed('mainMenu', > 'administration')) { >> $this->_helper->layout->enableLayout(); >> throw new Exception('Permission denied!'); >> } >> } >> >> Cheers, >> >> - Robert >> >> >> >> ______________________________________________________________________ >> __ This email has been scanned for all known viruses by the >> MessageLabs Email Security Service and the Macro 4 plc internal virus > protection system. >> ______________________________________________________________________ >> __ > > > ________________________________________________________________________ > This email has been scanned for all known viruses by the MessageLabs > Email Security Service and the Macro 4 plc internal virus protection > system. > ________________________________________________________________________ > > ________________________________________________________________________ > This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. > ________________________________________________________________________ ________________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. ________________________________________________________________________ ________________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. ________________________________________________________________________
