https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38130
Pedro Amorim <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] | |m --- Comment #11 from Pedro Amorim <[email protected]> --- (In reply to Jonathan Druart from comment #9) > If we do it for the library names on this view, we need to do it for all the > library columns (thinking about patrons right now but I am sure there are > others). And to be consistent, for all the other coded values: "special AVs" > (item types, cn source), regular AVs, patron category codes, etc. Agreed. > We will introduce additional JOINs and so maybe performance problems. This > needs to be investigated before we take this route IMO. > """ I've tested using Nick's randitems: https://github.com/kidclamp/handy-koha-script/blob/main/randitems.pl Before patches: searching for "cpl" using the datatable search input - average of 0.27 secs for 300 items. - average of 0.37 secs for 3000 items. After patches: searching for "centerville" (or cpl) using the datatable search input - average of 0.3 secs for 300 items. - average of 0.45 secs for 3000 items. This exercise should also be done for patrons (when that time comes) but from my testing, the performance impact seems negligible on this table. For me, this is enough to not block this, the enhancement is clearly needed and makes sense. As a rule of thumb, anything that is displayed on the table should be retrievable by a keyword search. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
