https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23875 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Ere Maijala from comment #5)
(In reply to Nick Clemens from comment #3)
In the mappings local-number is set as a string by default - should we change it to a number? I think in practice it will be a number, however, under ES at least I don't see why someone couldn't map local-number to 001 and manage their own control numbers with letters, so maybe string is okay as long as your numbers are built consistently?
Changing it to number would be scary, and I don't think this is really an issue. If we want to make sorting consistent, we could always left-pad the biblionumber with zeros, but I don't really like it since it wouldn't match the biblionumber field in MARC exactly. Alternatively we could have a hardcoded mapping to a numeric biblionumber field. Or make the tie-breaker sort field configurable. But since local-number gives us consistent results, I believe this is good enough for all practical purposes.
I am not sure if I understand the issue compeletely, but why would local-number be scary as a number? local-number is usually the biblionumber, right? And if it is, I am in doubt about what Nick says that you could just remap it to 001 - at least I would expect issues with that. I think being able to sort numerical on biblionumber is important so you can use it as a tie breaker as mentioned before, when all other criteria are the some. You you can sort from newer to older. If we don't sort numerical... that meanst 9 999 2 22 1 11 ... something like that? -- You are receiving this mail because: You are watching all bug changes.