The current code does track the visits, but it also includes other information (more accurately, it includes a string representation of the expanded dataId, looking like a python dict). The original datamodel was a binary table (CONFIG) with just the visits and pfsDesignId, but I think adding columns for 3 arms makes sense (I can certainly imagine times that we'll omit particular arms from the pfsObject), and adding the fiberId makes the lookup of e.g. the fibre position in the pfsConfig file easier.
price: do we need anything else in the dataId? I see things like:

{'field': 'OBJECT', 'dateObs': '2019-10-23', 'site': 'F', 'category': 'A', 'visit': 36, 'arm': 'b', 'spectrograph': 1, 'ccd': 0, 'filter': 'b', 'expTime': 900.0, 'dataType': 'OBJECT', 'taiObs': '2019-10-23', 'pfsDesignId': 1, 'slitOffset': 0.0}

visit, spectrograph and arm are sufficient to specify an image, but in combination with the objId (known if we're talking about a pfsObject) the spectrograph isn't required (since it can be obtained from the pfsConfig). So I think visit and arm are sufficient.

I propose to have visit and arm columns, but keep the identity column as a useful convenience.

rhl, would you mind signing off on this?

rhl would like for us to include fiberId, spectrograph, pfsDesignId in addition to visit and arm.

I took this opportunity to make things a lot more structured: removing the identity dict, and replacing it with a struct called Identity. I hope this will make things easier for users, who now no longer need to know the magic keywords visit, arm, spectrograph when they make a dataId; rather, the struct they need has the keywords in the API and the docs.

I believe rhl agreed with the ideas. Will reassign the review to hassan so he can approve the implementation.

Merged to master.