[db-wg] NWI-2 - displaying history for DB objects where available

(this may have been fixed, but this is how I understand things are today)

As currently implemented, the internal DB history of an object is tied to the fundamental DB object ID, which is (I believe) a monotonically rising/unique identifier. If an object is DEL and then ADD rather than UPD, the associated history of that object is disconnected: Not lost, it exists inside the RIPE SQL model but it has detached from the apparent resource, because the DEL/ADD sequence creates a new object with a new fundamental ID.

I say fundamental ID, distinct from the apparent unique primary key. The primary key of an INETNUM is not what drives the history mechanism: its the specific object ID which is internal.

This is one aspect of history-in-whois which is leading APNIC to consider a design for a JSON based approach, which presents the history of objects over time, irrespective of the ADD/DEL/ADD gaps.

I believe this needs to be part of your problem statement because as it stands, the history mechanism implies something about an object which may not be complete.

Additionally, we are considering a model which ties history to the start-end pairs of a range, alongside start-end pairs of dates, This is because (unlike prefix/len) its reasonably simple to construct canonical lists of the entire set of objects which span a time-window, and have an end of range bigger than the start, and a start of range less than the end, which encompasses the overlaps, splits and joins of that range.

A large amount of the data is affected by changing referenced objects. As others have noted, the RIPE NCC region has a significant issue in current data privacy legislation which guides limits on what can be seen. Noting that, we feel that the use cases of the history probably do need to reflect the history of changes of associated person, role and maintainer objects. Luckily the DB internal history mechanism tracks this, so we think we can take our basic tabular approach for start-end date and range pairs, and augment it to make the complete (JSON) block of a resource, and the specific state of associated records at that time. Most of this is pre-computable data, which will occupy disk (or database) but is not inherently complex in itself. There may be a lot of repetition (denormalized) but disk (and within limits memory) is cheap.

-George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/db-wg/attachments/20160711/c4dc4e17/attachment.sig>