When a user other than uid 1 attempts to edit a file node, the page never loads. Using the mysql interpreter and running 'SHOW FULL PROCESSLIST' shows that a query like this one is the problem:

/* username: rdf_db_rdf_query */ SELECT g.uri g, s.uri s, p.uri p, o.uri o, t.uri type, d.lang, d.data FROM rdf_data_file d
LEFT JOIN rdf_resources g ON d.gid = g.rid
INNER JOIN rdf_resources s ON d.sid = s.rid
INNER JOIN rdf_resources p ON d.pid = p.rid
LEFT JOIN rdf_resources o ON d.oid = o.rid
LEFT JOIN rdf_resources t ON d.tid = t.rid
WHERE (s.uri = 'bitcache://39eab0acaea321a65cd889182b8f49af2dce1b8b') AND (p.uri = 'http://purl.org/dc/elements/1.1/extent')
ORDER BY d.did ASC

Running 'SHOW FULL PROCESSLIST' multiple times shows that the values of s.uri and p.uri are always changing. The query takes .13 seconds when run by hand, but whatever is happening in drupal is causing it to just run and re-run with different values.

I'm using:
rdf 6.x-1.x-dev
fileframework 6.x-1.0-alpha4
bitcache 6.x-1.0-beta2
I was using the latest non-dev version of rdf, and tried upgrading that to see if that would resolve this issue - but it didn't.

Comments

justin.hopkins’s picture

Correction, after testing with a user having all permission, but not uid 1 - the edit page did come up. It took more than 45 seconds, and ran many many many queries like the one above...but it did eventually load. By contrast uid 1 loads the page in less than 5 seconds.

After further testing along these lines with other users, I've had varied results. The user who originally reported the problem is still unable to get the edit page to load, even when given the administrative role.

I'm going to have to really ferret this out obviously, so please let me know where I can start poking around. I'm wary to turn on mysql logging since it's likely running tens or hundreds of thousands of queries each time. Also, the trace module whites out my site.

Thoughts?

justin.hopkins’s picture

Further correction. The original users(not uid 1, but admin user) request for the 'edit' page was eventually fulfilled. It took > 5 minutes. I will continue experimenting and posting my results. Perhaps incidentally, he is responsible for uploading the majority of the files on the site.

justin.hopkins’s picture

Also posted this issue in the rdf issue queue #411068: File node 'edit' page will not load

miglius’s picture

Component: Code » Documentation
Category: bug » support
Priority: Critical » Normal
Status: Active » Closed (works as designed)

Try going to 'admin/settings/file/restriction' and clearing the checkbox at "Include generated files".

If this checkbox is unchecked, then the size of all files uploaded by the user is pulled directly from the database without going to the RDF storage.

On the other hand, if this is checked, then all file derivatives are counted, it means that there is a loop which checks all files uploaded by the user and then for each file it checks all file's derivatives from the RDF storage and then also pulls the size of the each derivative from the RDF as well.

I deliberately made this checkbox since anticipated the performance issues for the users which have uploaded a huge number of files.

miglius’s picture

Committed to cvs a patch which still optimizes the sql query for the case when generated files are not included in the file size count.