"CodeChecker server --postgresql" still create sqlite db

[sylvestre]

Starting with:
CodeChecker server --force-authentication -w /var/lib/jenkins/.codechecker --postgresql --dbname codechecker_config --dbport 5432 --dbusername codechecker_user --not-host-only --verbose debug

[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:219 from_cmdline_args() - Using PostgreSQL:
[16:15:21] {SERVER} [25340] <140409333311232> - server.py:453 main() - Connecting to product configuration database.
[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:370 connect() - Connecting to database...
[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:373 connect() - Checking if database is running at [localhost:5432]
[...]
[16:15:21] {SERVER} [25340] <140409333311232> - server.py:496 connect() - Connecting database for product 'firefox'
[16:15:21] {SERVER} [25340] <140409333311232> - server.py:500 connect() - Configuring schema and migration...
[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:231 from_cmdline_args() - Using SQLite:
[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:233 from_cmdline_args() - Database at /var/lib/jenkins/.codechecker/firefox.sqlite
[16:15:21] {DATABASE HANDLER} [25340] <140409333311232> - database.py:284 check_db_version() - Database version is compatible.

[dkrupp]

in this step-by-step guide it is describe how to store your results in postgres db.
https://github.com/Ericsson/codechecker/blob/master/docs/postgresql_setup.md

The database is not created automatically as before (and as currently in sqlite), you must create it before you start the server.

[whisperity]

--postgresql in the server's argument specifies that the configuration database resides on a Postgres server.

The firefox.sqlite is created because the product database is specified to be at said location. CodeChecker cmd products add also take a --sqlite and --postgresql (and --db-*) arguments which specify from where the analysis database is to be mounted from.

[Xazax-hun]

@whisperity, in that case it is very confusing which database is controlled by which option. I think, if someone wants to use postgres, probably it is a good idea to use it for all databases by default unless explicitly specified otherwise.

[whisperity]

It is well-documented in the help and in the written documentation. It is also logical as I explained above, the server takes the server's argument, while product add takes the product's.

Once a connection is set up in a particular way in the configuration database, it is used as it is. On the web interface, the SQLite/PostgreSQL distinction is made by the user.

You can't easily make it default if the server runs in PSQL mode, because it would result in an extra round (on the command-line) to query what mode the server runs in. Also, nothing ever guarantees that run databases are in the same database server as the config database. Setting up a SQLite product takes only one variable, while PSQL takes up to 5.

[sylvestre]

It is well-documented in the help and in the written documentation. It is also logical as I explained above

Probably from your perspective but as an external user who just want to run it, I find that unexpected and not following a principle of least astonishment

[whisperity]

How should we design it? Should we straight-up prohibit the usage of SQLite databases for analysis results if the configuration database is PostgreSQL and vica-versa?

[sylvestre]

yes, or having a single step to configure the database(s).
I guess in most of the cases, people who will run codechecker will only use it for one product (and probably on the same system)

[whisperity]

Simply starting CodeChecker server with no extra arguments at all (and assuming an empty ~/.codecheker directory) will automatically do that single step to configure a single Default product, especially aimed at the simplest use case ever.

If PSQL mode prohibits an SQLite database's existence, then we will end up with breaking a use case where, for example, a run database is residing in some shared storage location. The ability of having multiple products added to the same server opened up many new configuration options, unfortunately or not.