Hi Galen Does the issues table now only contain current issues? Ie no history of past issues How do we find out a borrowers reading history then? (People in NZ like this feature a lot, especially places like retirement homes so the library doesnt send them the same books all the time) Im hoping this is just being stored somewhere else now? (Thats the historical reason for multiple rows for the same itemnumber .. there should only ever be 1 with the returndate that is not null tho, IE only one that hasnt been returned) Chris On Thu, Oct 16, 2008 at 11:37 AM, Galen Charlton <galen.charlton@liblime.com> wrote:

Hi,

I've found at least one Koha database that has multiple issues rows for the same item but different patrons. This doesn't map well to the reality of loaning physical items, unless somebody's slipped in a Star Trek-style replicator feature, so I propose the following changes to constraints on the issues table:

1. Make itemnumber the primary key (and not null) - an item can be issued only once at any given time. 2. Make borrowernumber not null - a loan must be to a specific patron, and if the item is detached from the patron, there's no longer a loan. 3. Make renewals not null with a default value of 0. 4. Make issuedate not null - a loan must have started at a specific time; during a migration, if the issue date is not known, a made-up date can be supplied.

Comments?

Regards,

Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

Galen Charlton a écrit :

Hi,

I've found at least one Koha database that has multiple issues rows for the same item but different patrons. This doesn't map well to the reality of loaning physical items, unless somebody's slipped in a Star Trek-style replicator feature, so I propose the following changes to constraints on the issues table:

1. Make itemnumber the primary key (and not null) - an item can be issued only once at any given time. 2. Make borrowernumber not null - a loan must be to a specific patron, and if the item is detached from the patron, there's no longer a loan. I plan to say "no" here, but thinking of it, you're right... in many countries, the law requires that we anonymize the issues. So we set borrowernumber=0, but keep track of the fact that we issue item N to someone. So in old_issues, this constraint can't be set. in issues, it can, as we won't anonimyze an issue that is not returned.

3. Make renewals not null with a default value of 0. 4. Make issuedate not null - a loan must have started at a specific time; during a migration, if the issue date is not known, a made-up date can be supplied.

so, it's OK for me. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08