Improvements to settings handling

[vic0824]

Default values
Default values are only available in the source code and in the manual, both of which are normally not available in a production environment (which might be on a private LAN with no access to the Internet).
Every time we want to tweak some value, we have to look it up on the manual or in the source code.
I propose to put all the default values in a config file, which is read at start-up by both the Server and the Console (more on this below).

ContextConfiguration
I cannot think of any use case in which the difference between the GlobalConfiguration and the ContextConfiguration is relevant.
The GlobalConfiguration is already a volatile configuration, valid only for the current session (JVM), and the ContextConfiguration is derived from the GlobalConfiguration, so it has the same life-cycle.
I propose to eliminate the ContextConfiguration.

Server settings vs Database settings
The difference between changing a setting at JVM level and database level does not fit well with the whole range of settings, which include two distinct categories of settings:

• server settings
• database settings

Server settings must be set before the server is started, so it does not make sense to store them in the db, because by the time the db is opened, the server was already started with the default settings.
I propose to create separate mechanisms for handling server settings and database settings.
Some suggestions:

• server settings can only be specified at server level (they cannot be stored in the db) and their values are stored in a config file, which is read by the server at start-up. If the user wants to change a value, the user simply edits the config file.
• only server settings can be specified with "-Darcadedb.=", or alternatively, eliminate altogether this feature, which becomes unnecessary if all server settings are read from a config file

Selected settings available to the Console
Some settings affect the way a new database or a new schema object is created, so they should be visible to the Console, because it is possible to create a database and its schema objects using the Console.
Other settings are only relevant for the Server, so they should not be visible to the Console.
A good starting point would be to make all database settings available to the Console.
Some settings are border-line between server and database, so a detailed analysis of the various use cases should be conducted.

Pre-defined connection URLs for the Console
I think it would be useful to introduce a console-specific setting containing the connection url of the default database to connect to: I have been working with ArcadeDB for 3 months and I'm already fed up of typing the full URL every time.
A more general solution would be to create a config file containing a list of aliases and their corresponding URLs, so that you can simply type "connect alias1" and the Console will connect to "remote:localhost:8080/testDb1 testUser1 testPassword1"

I realize some of these proposed changes are quite radical, but in my experience they would be beneficial in the long run, because they will spare you wasting time answering stupid (for you) questions of frustrated users who don't understand how to configure ArcadeDB.
As an example, look at how many questions about Hsqldb usage are on the SourceForge page and on StackOverflow, even though Hsqldb has a 433-pages manual: Fred Toussi spends a lot of his time answering the same questions over and over.

[gramian]

My two cents:

Default values

• The documentation is downloadable, see: https://docs.arcadedb.com/ArcadeDB-manual.pdf solving the immediate problem.
• Having such default-values-configuration file just shifts this problem to a (IMHO much more dangerous) user responsibility. Now, as soon as this file is changed and in an isolated network, the admin has to document this changes, so future admins (including themselve) are aware that this is not a default default.

Server settings vs Database settings

Personally, I don't want to change these settings from "within" the database, ie studio or driver, but I may want to review them to verify behaviour. So storing settings in the DB can be useful.

Pre-defined connection URLs for the Console

I agree this can become cumbersome, I would suggest a command-line parameter or an environment variable. The latter would likely be much easier to implement, while the former would be more natural. Now if one wants to even avoid even typing addresses even once, then a wrapper script can be put around these solutions.

[gramian]

So the cmd line args need to be passed to console ctor and evaluated there if not empty?

[gramian]

I think it is good, it helps @vic0824 and just requires others to pass an exit at the end to keep current functionality.

[lvca]

Ok, created new issue #767

[lvca]

Ok, it's done: #767.

[lvca]

Now the console waits for commands (interactive mode) unless you execute an exit or you're starting the console in batch mode with bin/console.sh -b "connect mydatabase;select from log order by date desc limit 100"

[lvca]

I agree now there is no clear distinction between server and database settings. We could add a new property "scope" in the GlobalConfiguration enum to distinguish it, and then generate 3 tables in the docs: "JVM Settings", "Server Settings" and "Database Settings".

With this new property, we could filter the settings in the database configuration and the console, so no risks to set something not used or setting something in the wrong place.

With OrientDB we tried to make almost everybody happy, we implemented tons of features that only a few users effectively use that features. With ArcadeDB we have a totally different approach: keep the codebase as small as possible (we're still cleaning and removing code from the SQL Engine inherited from OrientDB). Having a larger codebase means harder to document, test, and maintain. Furthermore, it's harder to modify things without breaking more things.

In ArcadeDB we're always eager to add a new cool feature, only if:

• it's something we must have
• many users request it
• a sponsor pays for the feature and at the same time it could be beneficial for others

I like there's a single point where you can configure ArcadeDB (GlobalConfiguration). Also, the fact you can store the same settings in the database is easy and useful, so you don't have to set them every time and it's portable across multiple servers.

About the server setting configuration file, I see it could be useful having a config/server-configuration.json that simply keeps the configuration there, as a JSON, and at startup, the server just parses the JSON and apply the settings to the GlobalConfiguration instance. But at the same time, you could just create a script that passes those settings to the server, so having a configuration file wouldn't be a game changer but it'd make things even more confusing IMO.

The URL alias is a good idea if you use the console a lot, but you can still use the console history (up/down arrows) to get previous commands and as @gramian suggests, you can connect to the server from the command line, avoiding to write URL and username all the times. So again, not a real game changer IMO.