[Koha-bugs] [Bug 29386] background jobs table data field is a TEXT which is too small

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Nov 3 16:31:11 CET 2021


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29386

--- Comment #6 from Andrew Nugged <nugged at gmail.com> ---
In any case, going MEDIUMTEXT already makes Koha much more "stable", we already
have some problematic users worldwide now since announcing of this queueing
feature (I have three customers whose batch processing hiddenly failed because
of this since spring not once (sic!) ), so for me setting this to MEDIUMTEXT at
least gives "relatively much more stability", but:

Do we need to allow for operators to operate with >200K biblio-records and
>1.5M items in a batch? Because this is more business logic question, on which
we can't answer but life, let's make it "trials and errors" way but LET'S MAKE
VISIBLE the problem, 


i.e. I propose this:

1. set to MEDIUMTEXT, and ADD UI analysis/feedback with some "length estimator
and limiter", which is to fail with UI errors like:
   - "ERROR: batch processing of >200K biblios not yet supported"
   - "ERROR: batch processing of >1.5M items not yet supported"
saying even "yet" to signal to "feedback" from customers back to the community,

i.e. make it hard-fail on bigger amounts, to prevent HIDDEN ERRORS which is now
happening. Then if we will have requests from worldwide users - that can be
considered to be switched to LONGTEXT, if no other choice.


Anyway seems even with LONGTEXT it seems proper to make some "hard limited"
number of queued items or bilbios (accordingly) because otherwise, this will
become a "hidden error" anyway (ok, "potential" and "big numbers", but anyway).

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list