Thank you for explaining it, Evgenji.
I understand you argument, after all Oracle or SQL Server would not
point to a File either and in fact it is on the discretion of the DB,
how to deal with the connection string.

That said:  jdbc:h2:file:<file name> looks a lot like a Url/Uri.
And I would always try  jdbc:h2:file:/C:/foo first, followed by a
frustrating trial'n error until I figure out jdbc:h2:file:C:/foo (which
simply looks wrong to me!)

So I wonder: should we not try to accept valid Uris at least for the
 jdbc:h2:file: and  jdbc:h2:nio: variants?
Would you consider PRs covering that?

Best regards
Andreas


On Tue, 2020-11-24 at 05:22 -0800, Evgenij Ryazanov wrote:
> Hello.
> 
> JDBC connection URLs for H2 aren't related with URIs in any way.
> 
> jdbc:h2:<file name>, jdbc:h2:file:<file name>, and jdbc:h2:nio:<file
> name> mean the same in the current H2 and there are no good reasons
> to use file: or nio: prefixes. In older versions they were different
> (and they also were different between PageStore and MVStore engines).
> 
> There are other subsystems, such as niomapped:, async:, retry:,
> split:, encrypt:, zip: and so on and they can also be cascaded.
> 
> Not every URL for H2 contains a file name. mem: represents a normal
> in-memory database, memFS:, memLZF:, nioMemFS:, and nioMemLZF:
> represent alternative in-memory storages and H2 works with them in
> entirely different way (more like with with files).
> 
> tcp: and ssl: are used for remote connections. TCP server may have
> some configured base directory where database files can be located,
> but it also can use the whole file system of the server, it depends
> on its configuration.
> 
> Database files also have .mv.db or h2.db extensions, these extensions
> aren't specified in the URL. If MV_STORE setting is not specified,
> there is no way to get this extension from the URL, it depends on the
> actual file on the disk.
> 
> There is no reliable way to get the file name from the JDBC URL, but
> if you have a connection, you can try to use the DATABASE_PATH()
> function.
> 
> In the current H2 you can use
> CALL DATABASE_PATH() || CASE (SELECT CAST(SETTING_VALUE AS BOOLEAN)
> FROM INFORMATION_SCHEMA.SETTINGS WHERE SETTING_NAME = 'MV_STORE')
> WHEN TRUE THEN '.mv.db' ELSE '.h2.db' END;
> to get the file name if database uses the the default file system
> without any subsystems.
> 
> For 1.4.200 this command needs to be edited,
> because INFORMATION_SCHEMA.SETTINGS had different names of columns
> (NAME and VALUE).
> 
> If NULL is returned, the database is a normal in-memory database
> (without special in-memory file systems). To support more special
> cases, you need to check the result for async: and other prefixes
> (possibly cascaded).
> 
> You can also try to parse the URL itself, but you need to support
> more special cases and you need to know settings of all your servers,
> if you want to support the remote URLs properly. Perhaps you don't
> need the full paths on remote servers anyway, so you can only detect
> tcp: and ssl: prefixes.
> -- 
> You received this message because you are subscribed to the Google
> Groups "H2 Database" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to h2-database+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/h2-database/cf1aeb4a-fd88-46e3-aea4-76b4096881b4n%40googlegroups.com
> .

-- 
You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/9bd745cdf7b81217bbfb14894d9a3bcdd0639776.camel%40manticore-projects.com.

Reply via email to