feat: update sqlite to use a hand build schema

[ozym]

This is the next iteration on from the basic table layout, there has been more effort in normalisation. There are still some outstanding issues, one improvement would be to consolidate some of the tables.

[ardrigh]

@ozym I had a quick once over looking at the structs and a few of the sql queries where you might expect to call them, and it's not clear the sql queries are using the same field names.

eg query for start_time when the struct has start and end.

Are the fields being updated outside the structs before the sql queries are run?

[ozym]

@ozym I had a quick once over looking at the structs and a few of the sql queries where you might expect to call them, and it's not clear the sql queries are using the same field names.

eg query for start_time when the struct has start and end.

Are the fields being updated outside the structs before the sql queries are run?

If this is for the example code, then usually the mechanism is to do the SQL query (with the details of the schema) and then pass each resulting line into an extraction which then maps the order of the query output values into variable fields, which tend to be part of a struct.

e.g.

query := "SELECT make.make,sensor.start_date,sensor.end_date FROM <snip> WHERE <snip>";
then prepare this, so that when the query is run then the results will be scanned rows, where the "make" is in the first column, and in this case the start and end dates would be the second and third.

Then when you scan each row you can map them into a different structure, e.g.

type Sensor struct {
    Make string
    Start time.Time
    End time.Time
}

func() {
 ...
        sensors := make([]Sensor, 0)
        for results.Next() {
                var sensor Sensor

                if err := results.Scan(&sensor.Make, &sensor.Start, &sensor.End); err != nil {
                       error here.
                }

                sensors = append(sensors, sensor)
        }
...
}

etc.

[ozym]

For added context, I haven't tried to build an ORM in which case, yes the field names should map to sql values.

[ardrigh]

Cool thanks, I will have a proper read through

[MCorfy]

Looks good