Well, you're obviously holding an instance of you DB adapter in your ACL object. I hadn't realized
you'd extended the base class that much.
Nonetheless, it is a fairly easy to implement some logic in the __sleep and __wakeup magic methods
to destroy and re-initialize the DB connection.
On 12/02/2009 9:47 AM, Robert Castley wrote:
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:ja...@intraffic.net]
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:ja...@intraffic.net]
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
