Two issues came up in our discussions during the SysOp SIG meeting this week that we felt should get a bit of air time in the upcoming developer meeting. In the absense of a product owner for this area, we wanted to put these ideas in front of you in hopes that they can make their way in front of the right set of developers before the Madrid meeting. Perhaps these issues have already been explored/addressed, but if not it seemed like a good time to get them out there.

1) Consistency of API interfaces: The question was raised in the SysOps SIG as to whether is any attention being paid to making the batch/bulk API interfaces consistent in their interfaces and conventions. There's a good bit of effort in making the UI consistent across apps, and while it may not be as critical to make back-end APIs be consistent across, apps, this is one place where it seemed like it would be worth checking. If the right folks are thinking about it early enough in the process, it shouldn't be that difficult to have the batch/bulk interfaces behave in similar ways.

2) Concerns about the use of UUIDs for primary keys as it pertains to migrations: Currently, our existing ILS systems generally use numeric primary keys for data tables. As such, we can refer to bib records, patron records, etc. by their numeric IDs fairly reasonably. Linkages between records similarly rely on those keys. With FOLIO's use of UUIDs as the primary key, there is going to be a challenge in migration because we won't be able to rely on re-use of those keys as we migrate our data in. When looking at isolated records, it's not a huge deal. For example, we could put the Voyager BibID into a field in a metadata record, and be able to refer to it. But when we need to migrate in the holdings and items that are related to that bib, we need to be able to link the records together properly and we wouldn't be able to use that BibID. There is an issue of maintaining the referential integrity of the dataset that, while not insurmountable, is made much, much more complex (and potentially error-prone) by the change in primary key.