Hacker News new | ask | show | jobs
by devbent 943 days ago
> And we don't want to think about what server it's on, or what hard drive, or what folder. And we don't want to think about client protocols or query languages.

Different types of data are legal in different jurisdictions (for example the definition of PII data), the physical location of the hard drive matters.

When medical data is stored, where and how is important. When handling data that needs to, legally, needs an audit trail, abstractions won't do.

When data is needed at low latency, the details matter. When cost is important (egress charges per operation or counted by size of data transfered), details matter.

1 comments

> the physical location of the hard drive matters

Not exactly: what matters is the legal designation of the data storage device. The location of that device is one of many factors that "matter", but not to the application, or developer, or user. They only "matter" to the law. We aren't going to start writing UnitedStatesFileWrite() functions, now, are we?

Instead of considering the physical location of a hard drive, what we should be doing is querying a data storage object which has the properties we want:

  io_construct = DataStorage()
  storage_search = io_construct.DataStorageSearch({
    "contains": [
      { "legal": {
          "jurisdiction": {
            "location": [ {
              "country": "US",
              "state": "California"
            } ]
          }
        }
      },
      { "record": [ { "email": "foo@bar.domain" } ]
      }
    ]
  })
  with io_object as io_construct.AttachDataStorage(device = storage_search):
    io_object.read()
We should never have to think about what building a hard drive is located in, much less the complexities of dealing with specific data laws. The IO construct should deal with that.