Manage Deposits (Screen::Items) creates cache tables but doesn't use them

[drtjmb]

When Manage Deposits searches for the list of all eprints belonging to the current user a cache table is created and populated (in fact two cache tables are created - the second is a copy of the first but sorted into the appropriate display order).

However the cache table is never used eg. when moving through pages, changing the number of items displayed - ie, a new cache table is generated every time an "internal" link is clicked on the Manage Deposits page:

Database execute debug: UPDATE `counters` SET counter=LAST_INSERT_ID(counter+1) WHERE `countername` = 'cachemapid'
Database execute debug: INSERT INTO `cachemap` (`cachemapid`) VALUES (?)
Database execute debug: UPDATE `cachemap` SET `oneshot`=?, `created`=?, `searchexp`=?, `userid`=?, `lastused`=? WHERE `cachemapid`='56'
Database execute debug: CREATE TABLE `cache56` (`pos` integer NOT NULL, `eprintid` integer, PRIMARY KEY(`pos`)) DEFAULT CHARSET=utf8
INSERT INTO `cache56` VALUES (0,1)
INSERT INTO `cache56` VALUES (1,2)
INSERT INTO `cache56` VALUES (2,3)
INSERT INTO `cache56` VALUES (3,4)
INSERT INTO `cache56` VALUES (4,5)
[...]
INSERT INTO `cache56` VALUES (5997,5998)
INSERT INTO `cache56` VALUES (5998,5999)
INSERT INTO `cache56` VALUES (5999,6000)

[Emi94]

I encountered this issue too. The problem is that a cache table is created every time when "Manage Deposits" is visited, taking a long time to load the page. For a user with 885 deposits it takes about 30 seconds to load the page.

Can this be fixed please?

[prazetyo]

Yes...I also encountered this issue too. I hope this bug can be fixed.

[mpbraendle]

We see this issue, too. Having good system performance for submitters and editors that do daily work in the system is essential. Having to wait 30 seconds is a no-go. That issue should not be tagges as "area:low level".

[phluid61]

I've had another look at this. There seems to be an underlying problem with there being multiple ways to achieve similar outcomes -- in this case building a List. The List package itself calls db->cache, but doesn't ever query the database for an existing cached result set. And there is no convenient place to hook it in.

Incidentally, why does a List need to be cached before it can be reordered?

[jesusbagpuss]

I've been doing some thinking around this too. One possible (albeit not perfect) solution would be to add the cacheid to the user preferences field, and recall it from there. There may need to be a way for a user to 'forget'the cached set via the GUI somehow.

…

________________________________ From: Matthew Kerwin <notifications@github.com> Sent: 25 September 2018 02:23:06 To: eprints/eprints Cc: Subscribed Subject: Re: [eprints/eprints] Manage Deposits (Screen::Items) creates cache tables but doesn't use them (#221) I've had another look at this. There seems to be an underlying problem with there being multiple ways to achieve similar outcomes -- in this case building a List. The List package itself calls db->cache, but doesn't ever query the database for an existing cached result set. And there is no convenient place to hook it in. Incidentally, why does a List need to be cached before it can be reordered? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#221 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAzq8-M_iCLpi8BDEK47LzbIt_Exy9FEks5ueYV6gaJpZM4BwOxP>.