Console ignores value of server.databaseDirectory property

[vic0824]

ArcadeDB Version: v22.11.1

JDK Version: openjdk 11.0.12 2021-07-20 LTS

OpenJDK Runtime Environment Corretto-11.0.12.7.1 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.12.7.1 (build 11.0.12+7-LTS, mixed mode)

OS: CentOS release 6.9 (Final)

Expected behavior

the console allows connecting to a database stored in a non-default directory specified by the server.databaseDirectory (or GlobalConfiguration.SERVER_DATABASE_DIRECTORY) property.

Actual behavior

when connecting to a db stored in a non-default directory, the console cannot find it:

connect csrsdb
ERROR: Database './databases/csrsdb' not exists

The console adds a hard-coded "./databases" prefix to the path specified in the "connect" statement.
This can be easily verified by inspecting the "setRootPath(final String rootDirectory)" method of the Console class.
Also, "does not exist" would be more correct than "not exists"

Steps to reproduce

1 - start the server, setting the server.databaseDirectory property to a value different from the default and the arcadedb.server.defaultDatabases property to a valid database name
2 - start the console
3 - connect to the database

[lvca]

Thanks, @vic0824, I've already fixed all the typos as you suggested. About the db directory the console is using, I don't think it should use SERVER_DATABASE_DIRECTORY setting, because it's for the server.

I think it would be much easier to allow the console to open any database located in the local FS. While the server is forced to look only into its databases directory for security reasons, the console should be able to open any files.

[gramian]

And, you can start also the console with the option arcadedb.server.databaseDirectory=... which then the console recognizes and uses.

[vic0824]

The best design depends on the intended use cases of the Console.
What is the intended use of the Console? Currently it is not clear, because it supports two very different use cases:

1. connect to a local path: in this scenario, the Console uses the DatabaseFactory to open a "local" database
2. connect to a remote URL: in this scenario, the Console sends an http request to a running instance of the ArcadeDB Server

Use Case 1 only makes sense if there is no instance of the ArcadeDB server on the same host, but it doesn't perform a check and it does not warn the user.
If there is an instance of the ArcadeDB server running on the same host, and you use the console to connect to a database that is already opened by the server, you get:
2022-12-29 10:26:14.650 WARNI [EmbeddedDatabase] Database 'csrsdb' was not closed properly last time
2022-12-29 10:26:14.663 WARNI [TransactionManager] Started recovery of database 'csrsdb'
2022-12-29 10:26:14.670 WARNI [TransactionManager] Recovery of database 'csrsdb' completed

because it finds the database.lck file in the database directory.
I don't know exactly what the "recovery" does to the database opened in the server, but it does not look safe.
This is similar to the scenario in which you try to use DatabaseFactory to open a database which is already opened in an embedded server and for this reason I believe the console should print an error and not try to "recover" the database.

On the other hand, Use Case 2 only makes sense when there is a instance of ArcadeDB server running somewhere (it does not have to be on the same host) and therefore is a text-based alternative to Studio.

For what concerns the capability of opening any database in the filesystem, I guess it's fine, assuming it does not try to recover a locked database, but it should at least accept both relative and absolute paths, where a relative path is relative to user.dir, so that there is at least one use case in which you can use "connect [db_name]", which is the simplest, most intuitive and user-friendly syntax.
This means that the only way to connect to a database that is opened by an ArcadeDB server, is to use the more cumbersome "connect remote:[hostname]:[port_number]/[db_name] [username] [password]" syntax, which exposes the password in clear text.
By the way, the documentation use the "remote:" definition, but a URL includes the protocol, whereas the Console rejects any URL that starts with "http", so maybe it should be clarified.

[gramian]

Hi @vic0824 ,
I partially agree, that the console is not completely clear in its use. Maybe it would help if every server or database argument, no matter if local or remote, has to have a protocol (and no more remote:). So for example:

connect file://test

for a local database, and

connect http://user:password@host:port/db

for a remote database? And similarly for other commands. What is your opinion on these proposed changes, @lvca ?
I know this doesn't fix the problem above, but it could clarify the distinction between local and remote better (?), and, by file:/// any absolute path could be passed.

[lvca]

@gramian I think file:// already works, but for convenience, without any prefix file is taken. I like to manage better the case that the database is locked. 99% of the time is because a server is running and opened the database. For security reason, the files are locked.

But there could be the case when there are multiple server running on the same machine, so checking the server port is not enough. It could also be modified. We could check for the PID. The server writes the process PID on file, so we can just check if the process is running assuming it's the server.

[vic0824]

@lvca That seems a lot of work just to cover a rare corner case.
If the database is really locked by a server process, why do we care about which server did it? The console should print a warning and not do anything.
If the lck file is there because a server was not shut down cleanly, it's up to the server to perform the recovery the next time it starts.

[gramian]

I can look into a warning for a locked database in the console. Also, this explains #599 .

[lvca]

Fixed, now the console can take -Darcadedb.server.databaseDirectory=<?>