https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Alex Sassmannshausen <alex.sassmannshausen@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex.sassmannshausen@ptfs-e | |urope.com --- Comment #27 from Alex Sassmannshausen <alex.sassmannshausen@ptfs-europe.com> --- (In reply to Alex Arnaud from comment #25)

(In reply to Jonathan Druart from comment #24)

...

This <UNCHANGED> stuff smells like a very bad codding pattern. Could not we use empty string and undef/NULL to handle empty values?

Hello Jonathan,

I don't really see how to do that.

If you create a course item this way:

my $ci_id2 = ModCourseItem( itemnumber => $itemnumber, itype => '', ccode => 'BOOK', holdingbranch => '<UNCHANGED>', location => '<UNCHANGED>', );

or this way

my $ci_id2 = ModCourseItem( itemnumber => $itemnumber, ccode => 'BOOK', holdingbranch => '<UNCHANGED>', location => '<UNCHANGED>', );

This results to the same when getting the course with GetCourseItem: itype is undef. Empty or null value are retrieved the same and we are unable to know if the value has changed or not.

Yeah, it looks to me like: - either you need to add a boolean column for each field that can be changed when added to course-modifier to indicate the value was changed - you add a column with a parseable string that indicates which fields were changed - you use a magic string like '<UNCHANGED>' to indicate absence of change - you add a linking table, which has an entry for each itemnumber and each changed column The latter means we would remove the ccode, holdingbranch, location, itype fields from the course_items table, and would solve the code smell but might be more work to implement. Other than that, I recon the '<UNCHANGED>' is the most workable solution. my 2¢, Alex -- You are receiving this mail because: You are watching all bug changes.