[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Preventing duplicate entries in bookbags / record buckets

[Mike Rylander]

On Fri, Dec 18, 2009 at 10:58 AM, Dan Scott <dan at coffeecode.net> wrote:
> We've been using bookbags for our course reserves lists, and it's mostly
> been going well - particularly using the option to expose the book bags
> in a given skin and locale. I plan on adding the ability to set the
> chosen scope, as well, so that we're not showing the holdings across
> every library in the consortium. But that's an aside...
>
> In the mean time, we discovered that some of our reserves bookbags had a
> tremendous number of records in them. We don't have too many sadistic
> profs who assign insane amounts of readings, though; in most cases it's
> because there were duplicate records. Again, in most cases there were
> just two copies of a given record, but in the extreme case we had a
> bookbag with 57 duplicate copies of a single record. Bookbags are
> instantiated in the container.biblio_record_entry_bucket_item table, in
> case you don't have that on the tip of your fingers. This is the same
> table used to implement record buckets.
>
> (My assumption is that there is/was a bad interaction with the browser
> "Back" button that causes the addition and re-addition of records to a
> given book bag, but I haven't confirmed that yet. To be determined!)
>
> I checked on IRC and Bill Erickson said that some sites use bookbags as
> a "books I've read in a given order" list, and that therefore duplicates
> needed to be allowed for the occasion that a person would read the same
> book twice. Also, he mentioned the possibility of using a shared bookbag
> as a kind of ratings infrastructure, something like '''38 people added
> this record to the "Like" bookbag''' to generate ratings. I can
> understand the former rationale - even though it seems like a bit of an
> edge case - but the latter sounds a bit insane to me. (Sorry, Bill!)

You can blame that on me, actually.

It wouldn't be a bookbag specifically, but a different btype on the
container.  Basically, we'd autocreate, as needed, a container per
star rating (say) for each user, as they rate books (bib-level
objects), and place those into the appropriate star-container.  The
container infrastructure can be used in may different use-cases --
it's fairly generic.

IIRC, the "things I've read" container already has its own btype.

>
> Bill and Jason thought that having a checkbox for "allow duplicates" in
> the bookbag interface while using the existing database table would be a
> reasonable solution. In effect, the application would manage the data
> constraints. Me, I'm an old school database guy who wants the database
> to enforce constraints, so I would prefer to see a unique constraint
> added to the container.biblio_record_entry_bucket_item table, and if
> there's a requirement for a reading list that allows duplicate entries,
> we could shunt that off to a separate table rather than trying to keep
> everything as generic as possible at the database schema level.

I'd say, add a "unique_items" bool to the container table, and have a
trigger on the item table check that in a BEFORE UPDATE OR INSERT
trigger.  Eh?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com