Feat: add sighting types and queries to schema

[asgeija]

Defines the Sighting type, a query for one sighting by id and a query for a list with search, filter, sort and cursor pagination. Documents the pagination choice in the README.

[jonatsm]

Sighting.city is declared String! (never null), but in the database UFO_SIGHTINGS.LOCATION_ID is nullable. A sighting with no location has no city, so the resolver would return null for city.

I tested it with a fake resolver returning two sightings, one with city: null:

{"data":null,"errors":["Cannot return null for non-nullable field Sighting.city."]}

GraphQL handles a null in a field marked ! by making the field above it null, and repeats this upwards. Every level here is marked !: node: Sighting!, [SightingEdge!]! and SightingConnection!. So the null climbs all the way to the top, and the whole response becomes data: null, including totalCount and the 19 valid sightings. A single bad row would break an entire page of search results.

[asgeija]

Sighting.city is declared String! (never null), but in the database UFO_SIGHTINGS.LOCATION_ID is nullable. A sighting with no location has no city, so the resolver would return null for city.

I tested it with a fake resolver returning two sightings, one with city: null:

{"data":null,"errors":["Cannot return null for non-nullable field Sighting.city."]}

GraphQL handles a null in a field marked ! by making the field above it null, and repeats this upwards. Every level here is marked !: node: Sighting!, [SightingEdge!]! and SightingConnection!. So the null climbs all the way to the top, and the whole response becomes data: null, including totalCount and the 19 valid sightings. A single bad row would break an entire page of search results.

I've pushed a change that fixes this

[thortve]

datetime is documented as UTC, but NUFORC times are local wall-clock times (schema.ts:5)
The importer, the resolvers and the frontend date formatting will all be built to follow this description. If it says UTC, US sightings will show up on the wrong day. Nothing will throw an error, so nobody will notice until the data looks off. Fix it now by documenting the field as a local time without a time zone (e.g. "2005-01-01T00:30:00", no Z). It's a one-line doc change today. Later, it means fixing the importer, the API and the frontend together

[asgeija]

datetime is documented as UTC, but NUFORC times are local wall-clock times (schema.ts:5) The importer, the resolvers and the frontend date formatting will all be built to follow this description. If it says UTC, US sightings will show up on the wrong day. Nothing will throw an error, so nobody will notice until the data looks off. Fix it now by documenting the field as a local time without a time zone (e.g. "2005-01-01T00:30:00", no Z). It's a one-line doc change today. Later, it means fixing the importer, the API and the frontend together

You're right, I assumed it was UTC since the places are all over the world. Changed the description to local time
without a timezone.

[asgeija]

@thortve @jonatsm is this good to merge now?

[jonatsm]

Looks good!