Hi,
> I find the documentation about system properties rather confusing...
You mean, the Javadoc page? It's a bit unfortunate. The documentation
should only list the property name, the default value, and the
description. The internal constant name shouldn't be there.
I will add a feature request: "improve documentation of system
properties: only list the property names, default values, and
description".
Some system properties are per machine settings, and others are as a
last resort and temporary solution to work around a problem in the
application or database engine. Also, there are system properties to
enable features that are not yet fully tested or that are not backward
compatible. I will document that.
> It seems that there are 2 kinds of properties
> At this moment there seems to be 80 of them.
> 78 of them are all uppercase.
That's the internal constant name. You can ignore it.
> 2 are in camel case (lobCloseBetweenReads, runFinalize)
That's the internal constant name. Those are mutable to simplify
testing. But it's not something a user of the system needs to care
about.
> This can be set using a system property but also in the connection url.
The base dir can be set when starting the server (-baseDir option),
but not in the connection URL (as far as I know).
> The only way I have come up with to read this property is
> System.getProperty("h2.baseDir");
Do you actually need to read this property? Why?
> There are 33 of these and in most of them the criteria why a property is set
> in the connection seems quite arbitrary.
At the beginning, there were no system properties. The system
properties are meant as a last resort in case you do need to change a
default setting for some reason (for example, to tune the performance,
or to workaround a bug in the database) until the problem is solved in
the database engine.
> - COMPRESS_LOB
> But most of the time decisions like this are made per the database.
Yes, so therefore it needs to be a per-database setting and can't be a
system property.
> Also many of the connection properties I would like to protect so that no
> user could change the databases behaviour.
Are you talking about SQL injection? Most settings can only be changed
by an administrator.
> All properties should be system properties.
All important settings should be per-database. There should be no
system properties at all (that do need to be changed).
> Maybe the first step could be that we could have commandline parameters that
> would disallow any changes made through connections (eg. -restricted)
No. The database administrator should be allowed to change the
database specific settings.
Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
