Hi Galen, > Hi, > > On Wed, Apr 2, 2014 at 8:51 AM, Doug Kyle <[email protected]> wrote: >> Smart Float automates the redistribution of floating collections based >> on >> available shelf space and duplicate copies. Smart Float also allows >> automatic >> "re-homing" of items based on a number of circulations from the original >> library or a specified time frame. > > Looks like useful behavior for Evergreen to support. > >> Copy locations are the units of Smart Float operation. Copy locations >> are >> mapped to the following attributes that Smart Float uses to determine >> how to >> distribute copies. >> - active: if true, Smart Float will be used, otherwise traditional >> floating >> will occur. >> - items_allowed: the number of items the shelving location can hold. > > I'm curious about the relationship between org units and shelving > locations in the smart float configuration. In particular, the > existence of the items_allowed column makes me wonder if the code > handles both the case where each org unit owns a separate set of copy > locations and the case where org units for the libraries share a > common set of copy locations owned by a higher-level org unit. In the > latter case, is the smart float config able to express that different > libraries might have different capacities for a given shelving > location?
Yes, we have different capacities for a given shelving location at each branch that floats. Those branches have all the same locations, which are owned by the system in asset.copy_location. Smart_float.config would have an entry for each shelving location/branch combination specifying items_allowed, dups_threshold, etc. The smart_float.destination function pulls the config record based on copy.location and checkin org ( and copy.location and asset.call_number owning lib for the homing settings). > > It strikes me that an estimate of capacity for a shelving location (or > shelving location and OU combination) would be useful for purposes > beyond smart float. > >> The Grand Rapids Public Library is now running an initial version of >> Smart >> Float in production on Evergreen 2.2. I've committed a lightly tested >> version for Master in my working repository. > > I took a very brief glance at the patch. One thing that jumped out is > that the queries that join on the asset.copy table aren't excluding > deleted items. Once that's corrected, you likely won't need to define > a separate index on asset.copy.barcode; the existing partial index > should suffice. Ah, I should have figured the deleted exclusion, I was wondering why that existing index was not used, thanks! Doug. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: [email protected] > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org >
