RFD 0003: OOI Hashing #4004
RFD 0003: OOI Hashing #4004
Conversation
|
|
||
| # RFD 0003: OOI Hashing | ||
|
|
||
| ## Background |
There was a problem hiding this comment.
I'd like a little more explanation on why we chose to override the default hashing and implement hashing only on the primary-key fields: Because we cannot have two different objects in the graph with the same primary key, it makes sense to also have the rest of the codebase 'think' they are the same by hashing only those fields that would lead to different objects in the graph.
I'd also like a little more info on why and where this is problematic for the python code itself if we disregard the notion that we can only keep one version of two objects in the database If their primary key is the same.
Furthermore a bit more details on why this specifically is a problem in the context of dealing with Objects in nibbles where we want to 'see' changes on any field that is used/consumed/read/queried by the nibble, regardless of what the primary key's values are. For example, having TTL for a DNSRecord in the primary key is useless for our Graph, but you could still envision a nibble that alerts users of DNSRecords with TTL's that are either too long, or too short. Not being able to see TTL changes (because from the outside the hash of the ooi stayed the same) would mean we only get to run the Nibble once, which is obviously not what you'd want.
n.b. A test nibble doing exactly this (min / max on TTL based on a config) would be a great way of demonstrating this, and adding functionality.
Co-authored-by: Jan Klopper <[email protected]>
Co-authored-by: JP Bruins Slot <[email protected]>
Co-authored-by: JP Bruins Slot <[email protected]>
Co-authored-by: JP Bruins Slot <[email protected]>
|
Markdown rendered version: RFD 0003