H2 error [90011-187] - Need a way to use relative dir

[wagfeliz]

I am trying to create a database in linux where : 1) Its not in the user home 2) Dont require the client to inform the intire server path for the db file. 3) Needs to be diferent from the bin directory to prevent core dump failures. In the documentation it says you can use a url like this : jdbc:h2:file:data/sample but this url simple dosent work and get the follow error : Exception in thread "main" org.h2.jdbc.JdbcSQLException: A file path that is implicitly relative to the current working directory is not allowed in the database URL "jdbc:h2:file:db/datadb;TRACE_LEVEL_FILE=3". Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-187] What I am missing ? Obs: I know you can use ".", but what will be the url from the client in that case ??? Thanks, Wagfeliz

[Thomas Mueller]

Hi,

Many users ran into problems because they used something like "jdbc:h2:test" and then either didn't find the database file, or created a second database when running the application in a different directory. That's why in version 1.4.x, now relative path only work when using ".", as in "jdb:h2:./test".

The documentation is wrong. I will update it.

 

jdbc:h2:file:data/sample

It should be: jdbc:h2:file:./data/sample

 

Regards,

Thomas

[Johann Petrak]

I think that is an unfortunate change - it breaks practically all existing relative URL paths in my case because none of them includes that "./" part and it violates the specification of what a relative URL can be which nowhere excludes URLs without the "./" part. Actually, the "./" part is explicitly superfluous and usually a nuisance that one wants to get read of when normalizing URLs. 

In my case it may be a reason not to upgrade to 1.4 because the DB is embedded in a system which does its own URL-handling (part of which is a normalization that removes one or more "./" so there is very little I can do. 

Is there any chance to make it work with all relative URLs again? 

I know of no other database or other software which enforces this.

Johann

[Christian MICHON]

I'll second that, but maybe a setting could be added (unless it already exists) to switch this on or off. Like this we could use this switch to ease legacy issues while preserving the directions chosen by the lead devs of H2.

As for moving to 1.4.188, some times you have no choice but to move on. I recently tried to use linked table on SQlite database from ITIS (taxonomy) and it works only with 1.4.188. Anything else will trigger a NPE, and if not fixed on an older branch like 1.3, you have to move to the latest or use other tricks than linked tables.

[Thomas Mueller]

Hi,

> I think that is an unfortunate change

I understand it is unfortunate for you, however there were many people that made a mistake, and run into problems, because they didn't find the database file, or created multiple databases.

> because the DB is embedded in a system which does its own URL-handling (part of which is a normalization that removes one or more "./" so there is very little I can do.

If you can't change the application to use the prefix "jdbc:h2:./" instead "jdbc:h2:", then I'm sorry about that, but there is nothing I can do about it...

> but maybe a setting could be added (unless it already exists) to switch this on or off.

I think there are already too many switches...

Regards,
Thomas

--
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...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[Johann Petrak]

My point would have been that file URLs (and file paths in java) have well defined semantics and the JDBC URL here includes the path portion of a file URL. 

A large number of these path portions will get computed automatically. Your change (Also the one that requires the drive letter on 

Windows) enforces something that diverges from the standard way of doing things with file URLs. In my view, the previous 

implementation was correct, there was nothing broken that needed to be fixed, there apparently were just a few people who did not understand

relative file URLs.  I think it is odd to deal with this by changing the semantics of file URLs (which is the case by requiring that of two

semantically equivalent ways to write down a correct file path only the one is supported that includes a redundant part) just for this one application and 

requiring that anyone who wants to use H2 has to change their semantics of file URLs too. 

Anyone who knows about the semantics of URLs will expect "relPath" to work equally to "./relPath" because in practically all other

situation that is exactly how it works. With H2, it will require to look in the manual or post a question here to figure out the special

requirement imposed on relative paths.

I am very thankful for H2 which is a brilliant piece of software which has made my life incredibly easier many times already,

and I fully understand that this is your decision and I will find a way to work around this in my application (or just

use a previous version for now), please understand that my concerns are meant to be constructive and helpful in the long run and not

just something I am too lazy to change on my side!

Best,

  Johann

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscribe@googlegroups.com.

[Christian MICHON]

> I think there are already too many switches...

We barely got 48 switches... :-)

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscribe@googlegroups.com.

[Thomas Mueller]

Hi,

I understand the change is more work for you, and I'm sorry about that.

Most databases (Oracle, PostgreSQL,...) don't support directory or file names as part of the database URL. The JDBC API doesn't specify how directory or file names are encoded in the database URL. 

Many, many people ran into problems because they used database URLs of the form "jdbc:h2:test". They thought this uniquely identifies the database, probably because it does for most other databases (Oracle, PostgreSQL, MySQL,...). But not for H2. They tried that, and it worked, even thought it's not documented anywhere in the H2 documentation. But it didn't do what they wanted.

Maybe in the future "jdbc:h2:test" should be supported again, but mean "root directory" or "home directory". That way it would work correctly for most people, and they don't have to read the docs.

Regards,

Thomas

 

  Johann

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.

To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

--
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...@googlegroups.com.