5 ms·

That's only technically true. As soon as you need to implement anything beyond func (db* Database) GetEmployee(id int) (string, error) func (db* Databa

That's only technically true. As soon as you need to implement anything beyond func (db* Database) GetEmployee(id int) (string, error) func (db* Database) SetEmployee(id int, value string) error even just something like func (db* Database) ListByDepartment(departmentID int) ([]string, error) You have some builtin assumptions about the shape of your data, i.e. a schema.

karmakurtisaani 4y ago
Nope. That's a problem of your code, not a schema on the database. You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema, and you're safe again. You could have cats and dogs and cars in your employee database and not run into problems. In fact, this is how you have to work when you're dealing with large amounts of unstructured data.
- stouset 4y ago
  > You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema Again, you have a schema. It's just invisible and implicit, and you have no tools to manage, enforce, or deal with it.
  - karmakurtisaani 4y ago
    If you define it like that, what's the point of the concept of schema at all? When I say no schema, I mean the user has no control over what's in the data. They can query for employee id's, pet names, birthdays, etc., and get back meaningful data or just Nones. Thinking about a schema this way is useful.
unconed 4y ago
The big thing I find that strict type aficionados get wrong is that it is immensely useful in practice to be able to read data that your program only needs to understand a subset of, while still being able to reserialize it intact and pass it on. It allows you to e.g. evolve systems in a backwards compatible way without having to update every single component in a pipeline in lockstep. Most marshalling/unmarshalling systems can't do this.
- majewsky 4y ago
  Can you elaborate on which systems those are? Every one I've used so far can deal with incomplete types, either through a document-level or type-level escape hatch. For example, in Go, encoding/json has an option to DisallowUnknownFields that even defaults to false. And even if you enable that, there's the option of soaking up unknown object keys into a map[string]any member field on the level of each individual struct type.
  - unconed 4y ago
    It depends. Sometimes the marshalling layer doesn't support it, because it's directly unserializing to a native struct via codegen. Often the app 's other types are too rigid to carry extra hierarchical metadata along even if you did unserialize it. And often it's the devs themselves that are averse to anything not rigidly typed or capable of inconsistent or incomplete states, because it's less pure or ergonomic... even though being able to store an incomplete record as a draft is an affordance everyone needs. ie. doesn't matter if Go can unserialize like this if the devs on your team hate the idea

karmakurtisaani 4y ago

Nope. That's a problem of your code, not a schema on the database. You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema, and you're safe again. You could have cats and dogs and cars in your employee database and not run into problems. In fact, this is how you have to work when you're dealing with large amounts of unstructured data.

stouset 4y ago
> You could have those functions return something optional, where a None is returned when the data doesn't conform to the assumed schema Again, you have a schema. It's just invisible and implicit, and you have no tools to manage, enforce, or deal with it.
- karmakurtisaani 4y ago
  If you define it like that, what's the point of the concept of schema at all? When I say no schema, I mean the user has no control over what's in the data. They can query for employee id's, pet names, birthdays, etc., and get back meaningful data or just Nones. Thinking about a schema this way is useful.

unconed 4y ago

The big thing I find that strict type aficionados get wrong is that it is immensely useful in practice to be able to read data that your program only needs to understand a subset of, while still being able to reserialize it intact and pass it on. It allows you to e.g. evolve systems in a backwards compatible way without having to update every single component in a pipeline in lockstep. Most marshalling/unmarshalling systems can't do this.

majewsky 4y ago
Can you elaborate on which systems those are? Every one I've used so far can deal with incomplete types, either through a document-level or type-level escape hatch. For example, in Go, encoding/json has an option to DisallowUnknownFields that even defaults to false. And even if you enable that, there's the option of soaking up unknown object keys into a map[string]any member field on the level of each individual struct type.
- unconed 4y ago
  It depends. Sometimes the marshalling layer doesn't support it, because it's directly unserializing to a native struct via codegen. Often the app 's other types are too rigid to carry extra hierarchical metadata along even if you did unserialize it. And often it's the devs themselves that are averse to anything not rigidly typed or capable of inconsistent or incomplete states, because it's less pure or ergonomic... even though being able to store an incomplete record as a draft is an affordance everyone needs. ie. doesn't matter if Go can unserialize like this if the devs on your team hate the idea