On Tue, Feb 8, 2011 at 4:36 AM, Arno Kuhl <akuhl@xxxxxxxxxxxx> wrote:
> But it might be an option if done once at the start of each
> search or list request, and then use that temporary modified result set for
> subsequent requests on the same set.
Instead of serializing the articles, you only need their IDs. Using
$sql .= ' where id in (' . implode(',', $ids) . ')';
you can load the data for a page of results in a single query. Storing the
IDs is much cheaper than the articles.
If the permissions are fairly static (i.e. access for user X to article Y
doesn't change every two minutes) you could create a calculated permission
table as a many-to-many between user and article. Here's the logic flow for
a query:
1. Run the query to find matching article IDs
2. Load permissions from table for all IDs
3. For each article without a calculated permission, calculate it and insert
a row (do a batch insert to save time)
If you flag the query in the middle tier as having been processed as above,
you can join to the calculated permissions each time you need another page.
The downside is that the code that runs the queries has to operate in two
modes: raw and joined to the permissions. If most users end up querying for
all articles, the table could grow. Plus you need to purge rows any time the
permissions for an article/user changes which could get fairly complicated.
On Tue, Feb 8, 2011 at 5:17 AM, Tolas Anon <tolas777@xxxxxxxxx> wrote:
> And it's bad form to display articles in search results that aren't allowed
> to be viewed.
On Tue, Feb 8, 2011 at 4:36 AM, Arno Kuhl <akuhl@xxxxxxxxxxxx> wrote:
> Now there's a requirement to not display the article title in category
> lists
> and search results if it cannot be viewed.
:)
David
