Add handling for isNewerVersionOf

[iannesbitt]

No description provided.

[iannesbitt]

This is tricky because there's no way to set obsoletedBy when the PID doesn't exist on the CN yet. So perhaps this would be best as a two-pronged approach, where the obsoletes is set in mnlite, then obsoletedBy is set on the CN after those objects get synchronized.

When isNewerVersionOf is in the JSON-LD:

1. Look up the ID on the CN. If it exists:
2. Set obsoletes in mnlite to the CN object being obsoleted
3. Once the objects are harvested, run an operation to link each chain that has an obsoletes item in its first mnlite object to the version it obsoletes in the CN. Follow that linkage and set obsoletedBy in the CN object sysmeta.

[iannesbitt]

If the object being obsoleted is in mnlite, this becomes a much simpler operation because all logic can be contained within. mnlite should check its own database for PIDs that match first, then proceed to doing a lookup on the CN if nothing is found. I think this would be handled in opersist.OPersist.addThing().

[mbjones]

Once the objects are harvested, run an operation to link each chain that has an obsoletes item in its first mnlite object to the version it obsoletes in the CN. Follow that linkage and set obsoletedBy in the CN object sysmeta

@iannesbitt I'm not sure you need to do this. If you look up the object on the CN to get the prior PID and set obsoletes to that PID on mnlite, when the CN harvests that record, it should see that the new record obsoletes the old PID, and it sets obsoletedBy for the old PID (IIRC). I think you only have to set one half of the relationship. Could be wrong, but worth checking on that.

[iannesbitt]

That would be very helpful, I'll check. Thanks for the tip

[iannesbitt]

I'm wondering if perhaps this is a MN API function that was not built into mnlite and does not work when harvesting documents to a CN. I can build in something similar for mnlite, but it will not quite be the same, as it can't assume that all documents being referenced are within mnlite itself.

[iannesbitt]

Still getting catch-22 errors from the CN when trying to make modifications to the system metadata. It wants me to be making them on the MN, but the MN object doesn't exist anymore.

I assume this means I need to be making modifications directly to the database to obsolete the old objects, which is always a lot scarier.

[mbjones]

Yes, that is right. The access control rules for system metadata say that the only identities that can change system metadata for an object are the original node identity, and that it has to be at the original location. @taojing2002 has done some direct patching to fix these issues up, and he may have a recommended route to help automate your version change updates.