Comment 5 for bug 1528924

After some experimentation(and more ongoing poking around), my thoughts would be that going the pcrud route would be ideal IF we can get the circ information once through itemSvc, and integrate it into our copy, rather than having it in both the list and detail controllers. It would be more complicated than a quick port of the existing usage in the detail controller, but it would also likely have the least calls happening. I've been able to get close to this, but each attempt runs just shy of results - usually having to do with itemSvc.copy not liking the added circ information, if it even finds it at all.

The main reason I think Pcrud is the way to go here is because of the measure of control we're getting with Pcrud. Using the Perl API comes with a lot of benefits here, but the sheer amount of information we return seems like it might be wasteful, resource-wise. It will also need a bit of extra work to get required information from the bib record(that, or I haven't been fleshing things as well as I should be able to, both are possible). That's not to say that using Pcrud for the circ information won't be tricky.

The reason for wanting it in itemSvc, besides just avoiding unnecessary code duplication, is that we could theoretically get the information for each item all at once - In the details view, loadCurrentCirc has the luxury of working with a single item. In the list view, we're working with multiple items. If the Pcrud allows getting everything at once, we'll be looking at less risk of instability/slowdown on very large item lists(not 100% sure this would happen, but it seems like something that might).

I'll continue poking around, and try to find a way to contradict myself on this, but I'm also going to leave this up for grabs until I think I've figured out something more substantial.