[ninsbl]

Users may have run t.connect in a mapset (esp. in their current mapset), so the connection information is written to the VAR file, but the tgis DB is not created. The recent changes to tgis.init() did not account for that possibility and DB creation failed.
So, the following failed with unexpected error messages:

t.connect -d
t.list type=strds
t.create output=test type=strds temporaltype=absolute title=test description=test

With this PR the above should be good again and also the related test (tests/grass_temporal_core_init_skip_db_test.py) passes.

[lucadelu]

I works for me

[petrasovaa]

Selected AI review points:

• pg connection leak in init() (core.py:771-781 on the PR branch): for the pg backend, dbif.connect() runs during the db_exists check; when the tables are missing, the old code reused that connection in create_temporal_database(dbif) and closed it there. The new code creates a second, dedicated connection and never closes dbif. Add a dbif.close() on the fall-through path (or close right after the pg check).
• Pre-existing bug adjacent to the new call: DBConnection.init sets self.dbstring = tgis_database_string when dbstring is None, then unconditionally overwrites it with self.dbstring = dbstring (i.e., None). The PR's call passes dbstring explicitly so it's unaffected, but since this PR leans on DBConnection construction, fixing that dead fallback here (or in a follow-up) would be cheap.*
• the described scenario is not actually covered by a test
• execute_transaction() still has mapset not in self.tgis_mapsets.keys()
• On a brand-new mapset, init() constructs SQLDatabaseInterfaceConnection() before creating the DB, so every first t.* command in a fresh mapset now prints the "database file does not exist" warning immediately before creating that file. The warning is genuinely useful in the skip_db_init path (it's the user's only clue in the t.list case), so it can't simply be dropped, but suppressing it for the current mapset when init() is about to create the DB would remove a confusing message from the most common first-run flow.

[ninsbl]

• pg connection leak in init() (core.py:771-781 on the PR branch):

addressed with closing dbif for pg path

• Pre-existing bug adjacent to the new call: DBConnection.init (...) when dbstring is None

Isn't this bug just theoretical? dbstring should only be none if tgis.init() is not run. With tgis.init(skip_db_init=True) the global(s) may None, but a connection attempt is only made for "valid" tgis_mapsets. If the SQLDatabaseConnectionInterface in that case, does not contain any tgis_mapsets, tools that skip DB initialization should inform the user that no tgis_mapset is available and exit (with either a warning (like t.list) or an error e.g. in case of t.info).

• the described scenario is not actually covered by a test

Added a test for half initialized mapsets. It could have gone other places as well, not sure, as the issue happend only for a specific order of tools run (or more specific t.connect before other temporal tools).

• execute_transaction() still has mapset not in self.tgis_mapsets.keys():

removed

• every first t.* command in a fresh mapset now prints the "database file does not exist" warning

This consistent with behavior in e.g. 8.4.2, the point of the SQLDatabaseInterfaceConnection() in init() has been to check if a DB exists and can be used.

I also tried to clarify what t.connect does in the manual, to avoid confusion that was behind this bug...

[veroandreo]

I only made some minor suggestions on the manual. t.list triggered an error related to Python 3.14, @petrasovaa was working on a patch for it.

[ninsbl]

Warning messages when creating the DB are now de-escalted to verbose messages, making behavior mor consistent with vector data ...