Cue positions are stored as doubles, not ints.

[ywwg]

This results in cue points being fractionally incorrect when loaded and increases the chance that a cue point will have the "invalid" value of -1.0

[daschuer]

Do we also need to update the Schema or does it work magically?

[Holzhaus]

Do we also need to update the Schema or does it work magically?

From schema.xml:

      CREATE TABLE IF NOT EXISTS cues (
        ...
        position INTEGER DEFAULT -1 NOT NULL,
        ...

Note that SQLite is NOT type safe. Maybe we should start enforcing STRICT mode, to prevent storing the wrong type:

SQLite uses a more general dynamic type system. In SQLite, the datatype of a value is associated with the value itself, not with its container. The dynamic type system of SQLite is backwards compatible with the more common static type systems of other database engines in the sense that SQL statements that work on statically typed databases work the same way in SQLite. However, the dynamic typing in SQLite allows it to do things which are not possible in traditional rigidly typed databases. Flexible typing is a feature of SQLite, not a bug.

Update: As of version 3.37.0 (2021-11-27), SQLite provides STRICT tables that do rigid type enforcement, for developers who prefer that kind of thing.

https://www.sqlite.org/datatype3.html

[Holzhaus]

We should also remove the default value IMHO. A cue should never have "no position", and that way we avoid having to define the "invalid" constant in multiple places (1x in cpp, 1x in SQL).

[ywwg]

The problem is that "-1" is used in code, including controller configs, to mean "no position". So unfortunately we have to avoid storing cues with that value completely. This sucks but at the end of the day trying to fix this is harder than just working around it.

[daschuer]

LGTM.
I think we can merge this here and discuss the schema migration here:
#11000