v0.1.0

Changed

• Breaking: the database is chosen by TANGO_DB_DSN's scheme alone, and TANGO_DB_DIALECT is retired: setting it is now an error. tango.LoadDBDSNFromEnv and tango.LoadDBDialectFromEnv are replaced by tango.LoadDBConfigFromEnv, which returns a db.DSN carrying the dialect, driver name and connection string together.
  • Upgrade: put the scheme in the DSN (TANGO_DB_DSN=postgres://…, or sqlite://app.db; unset still means sqlite://app.db), drop TANGO_DB_DIALECT, and replace the two loader calls with dsn, err := tango.LoadDBConfigFromEnv() followed by sql.Open(dsn.Driver, dsn.Source) and dsn.Dialect. Projects generated by tango newproject from this release on already do this.
• Breaking: tango makemigrations refuses to write a migration that drops a table or column unless each drop is authorised with --allow-drop app.Model or --allow-drop app.Model.Field, and refuses model changes no migration can express (a narrowing type change, a change of primary key or of a foreign key's target). A refused run writes nothing and prints the commands to choose between.
  • Upgrade: if a run is refused, declare a rename with --rename or authorise the drop with --allow-drop, as the error message shows.
• Breaking: migration.Diff and migration.DiffModels return an error alongside the migrations. These are part of the CLI-internal migration surface, which applications don't normally call.
  • Upgrade: handle the second return value.
• SQLite writers wait up to five seconds for a held lock instead of failing at once with database is locked.
• Breaking: realtime/websocket.View gained a variadic ...ViewOption parameter. Calls compile unchanged, but code that stores View in a variable of its old function type no longer compiles.
  • Upgrade: add ...websocket.ViewOption to that variable's function type, or call View directly.

Added

• db.ParseDSN, which parses a scheme-qualified DSN into a db.DSN.
• Renaming a field or a model with tango makemigrations --rename, which keeps the column or table and its rows.
• Widening type changes (integer to real or text, real to text, boolean to integer or text) through the new AlterColumnType step.
• The public testdb package: an app's own tests get a fresh database for the run's Test dialect, chosen by TANGO_TEST_DSN.
• examples/board, the tutorial's app, tested end to end on SQLite and PostgreSQL.
• realtime/websocket.View takes options: WithOriginPatterns and WithInsecureSkipVerify configure the upgrade's origin check.

Fixed

• Dropping a column on SQLite keeps everything else about the table: rows, indexes, unique constraints, foreign keys in both directions, defaults, NOT NULL and the primary key.
• NULL reads as the zero value, and an unset foreign key is written as NULL.
• Cookies are marked Secure behind a TLS-terminating proxy that sets X-Forwarded-Proto.
• Application sessions work on PostgreSQL.
• Times read back in UTC on every dialect.
• Generated migrations order their steps, and migrations across apps, by foreign key, so they apply on PostgreSQL.
• Migration files generated by v0.0.1 and v0.0.2 apply and roll back on PostgreSQL even when a table references one whose name sorts after it: the runner now creates referenced tables first and drops referencing tables first within a migration.
• Cascade delete handles circular foreign key references.
• Every SQL identifier tanGO generates is quoted, so a model named after a reserved word (User, Order) works on both dialects.
• Creating a row with an explicit ID on PostgreSQL advances the ID sequence.
• tango newproject keeps its standard-library imports in one sorted group.