Apologies for top-posting. Thanks Jonathan and Katrin for what is obviously
a close look into "item types."
Maybe I've missed some detail, so, while I am a great believer in tidying
up code, could I ask what the functional gains are?
I've looked at the Wiki page mentioned below, and it seems as though the
French and USA libraries difference was "abandoned" (2010? v.3.0 ==> 3.2)
but implies that it was no longer relevant (problem fixed?)
Katrin reinforces some points that "jump out" for me:
- updating MySQL databases at structural level can have widespread
repercussions.
- these repercussions impact the (hundreds? of) Perl scripts (and
possibly .css, .js, .tt, etc) files in the various Koha distributions --
testing and QA will be challenging at the very least.
- (as a consequence?) any institution using a "pre-MySQL update"
version of Koha as either backup or production server, will need additional
scripts to ensure dump/restore procedures (we certainly cannot take the
risk of updating backup and production simultaneously without at least one
bullet-proof "sandbox.") Add to this Katrin's well-taken point on complete
Zebra re-indexing.
- there are also potential repercussions in any user customization
-- MySQL "reports", .css and .js which the Koha community has encouraged,
possibly .inc, .xml, .xsl and .tt which we have probably occasionally
encouraged -- and possibly elsewhere. A quick look at our internal
"reports" shows that we have at least nineteen that use various flavours of
item types.)
"Return on investment" (ROI) is perhaps an over-utilized catchphrase, but
can we please define the "production gains" (even if code beauty suffers a
tad)?
Many thanks and best (seasonal) regards,
Paul
P.S. Philosophically, would it be possible to consider a "major version"
change. Some fundamental deltas (ElasticSearch and others, as well as code
cleaning -- C4auth springs to mind) could be incorporated into Koha 4.xx
and backwards compatibility would not necessarily be an absolute assumption.)
At 08:24 AM 12/23/2015 +0100, Katrin Fischer wrote:
Hi Jonathan,
thx for looking into this!
Am 17.12.2015 um 17:41 schrieb Jonathan Druart:
> Update DB migration:
> 1/ add column biblio.biblio_type
> 2/ update biblio.biblio_type with biblioitems.itemtype
> 3/ rename items.itype with items.item_type
> 4/ set items.item_type = biblio.biblio_type if items.item_type is not
> defined (or if item_level_itypes is not set?)
> 5/ rename deleteditems.itype with items.item_type, and don't update it
(right?)
Hm, I think I'd update it for consistency and easier use for reporting.
> 6/ drop column biblioitems.itemtype
> 7/ rename course_items.itype with course_items.item_type (to be consistent)
I am not sure about renaming the columns. Some thoughts:
Both the itemtype on items and on biblio level will still refer to an
entry in the itemtypes table. So if we rename, maybe we should reflect
the connection somehow.
It also looks like we are using 'itemtype' over 'item_type' in a lot of
other tables: statistics, branchrules, default_branch_item_rules,
issuingrules, suggestions...
I think changing items.itype to items.itemtype would make sense to me.
For record level... I am not sure about moving from biblioitems to
biblio, it will mean that a lot of the reports will be broken and we
probably can't fix them easily with a script.
> Then we will have to replace the notices ^items.itype^items.item_type^
> and ^biblioitems.itemtype^biblio.biblio_type^ should solve the
> problem.
We should think about doing something similar to the custom SQL reports
- I think there are probably a lot in all the databases that use the
itemtypes in some way.
> Looking at the code, I have found some places where I am not sure how
> to fix the display:
> 1/ For instance on the detail page of a biblio, or when a user place a
> hold, the item type is display either *on top* of the items list, or
> *in* a specific column of the table.
> Which makes sense. If we remove the pref, we have 3 choices:
> a. always display the item type in the table
> b. display the item type on top only if all item types are identical
> at the biblio type (will require some additional loops)
> c. display both and set a css class: the library will be able to
> hide the one it wants
> d. the answer d
Hm, for me it's either a or c. Or maybe d? ;)
> 2/ The change will require a complete reindexation of zebra: the index
> will be renamed (itype => item_type, mc-itype => mc-item_type,
> itemtype => biblio_type, mc-itemtype => mc-biblio_type).
> Is it acceptable?
Hm, I am not sure how commonly people reindex after updating. Generally
I think it's a good idea, but I am not sure we have this documented
well. Could we avoid renaming maybe and use aliases so the old index
names still work?
> I think I can produce a patch in 2 days of work (which is nothing
> compared to the number of days Koha developpers have lost to
> understand how this code works...), but it will require a lot of deep
> testing.
> It will really hard to provide tests for this change since it impacts
> a lot of file, but I will write some for the most common subroutines.
>
> I would like some people engaged in the signoff process, not to let
> the patches in the signoff queue too long.
>
> Cheers,
> Jonathan
>
> 2015-12-11 12:04 GMT+00:00 Jonathan Druart
> <jonathan.dru...@bugs.koha-community.org>:
>> Hi devs,
>>
>> Friday is a good day for this kind of questions, fasten your seat belt
>> for a time travel.
>>
>> As many of you know, the item type is not correctly managed all around
>> the different Koha modules. Sometimes it's, sometimes it's not.
>> The main issue is that we deal with it at too many places and the code
>> is not clean/centralised at all.
>>
>> So I have searched for previous discussions on this subject and I have
>> found this "Abandoned RFC" on the wiki :
>>
http://wiki.koha-community.org/wiki/Mandate_item-level_circulation_rules_RFC
>> filled from this koha-devel thread
>>
http://lists.koha-community.org/pipermail/koha-devel/2008-October/031144.html
>>
>> The questions are:
>> 1/ Is this still valid?
>> 2/ Is there something missing in the different steps described?
>> 3/ Does someone have some other suggestions to do?
>>
>> I would be happy to provide this change but first I would like to get
>> confirmation about it and get people involved in signoffing/QAing the
>> possible patch set.
>>
>> Cheers,
>> Jonathan
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
