Setting Default Values

[Bikingman]

Hi everyone - I hope this is the right place to open this discussion. Let me know if I should post this content somewhere else.

I'm interested to hear if others have thoughts on establishing default values in certain fields within the TIDES configuration. For example, count-based fields could be specified with 0 as the default value. This additional configuration seems useful for DB administrators and transit analysts, especially those working with TIDES in SQL databases. Default values could mainly overcome the problem of recording NULLs where 0 or other values should be recorded for a given observation.

To give a sense of what I have in mind, here's what the count field from the passenger_events table might look like with the new constraint.

{
      "name": "count",
      "type": "integer",
      "title": "Event count",
      "description": "Count for this event, e.g., 3 for a Passenger Boarding event with 3 boardings, default is  `1`",
      "constraints": {
        "minimum": 0,
        "default": 1
      }
}

I'm currently working on a project involving TIDES, and I have experience with this configuration. So I'm happy to provide a hand in building a PR if others think specifying default values would be useful. My gut tells me any count-based fields and any fields with a default value already specified, are good places to start.

[botanize]

Hi @Bikingman, thanks for starting the discussion.

I see your point. Different fields might have different default values, so it would be nice to have those clearly defined in a way that the analyst or DBA doesn't have to wade through the description of the field, and that could be used by code to automatically generate the constraint when loading the data.

passenger_events.count might be the only field that currently has a default value defined. We could either

• make the field required, which would eliminate the "how do I interpret a null value in an optional field" problem by eliminating the possibility of a null value, or
• add the default parameter to the constraints, mimicking SQL syntax, the default constraint would be required for any optional field where a null value should be interpreted as something other than null.

default is not currently part of the frictionless table-schema, so if we choose to keep the count field optional we'd have to implement it through a custom field and ideally a custom profile, see #93.

I like the flexibility the default constraint provides relative to the "make fields with default values required" option.