Hi Sven, I'll take that into account. I did not think about using an empty host/port pair, maybe because of the extra slash.

Also, I do not need to convert the file name to a file reference. That is done in sqlite by the sqlite library itself, so it's less work for the driver. The only need I need to do is:

��- for nbsqlite get the file name

��- for opendbx get the full file name and split into directory��+ file name because they are two different arguments for the library.

Now, having a look at what we can do with znurl

In windows it looks that we are ok

'sqlite3:///c:/myDirectory/myfile.db' asUrl path.

�� "'c:/myDirectory/myfile.db'"

'sqlite3:///c:\myDirectory\myfile.db' asUrl path.

�� "'c:\myDirectory\myfile.db'"

But in linux even if I put extra slashes it keeps removing them... And it makes difficult to recognize relative from absolute file paths:

"Relative path��c/myDirectory/myfile.db OK"

'sqlite3:///c/myDirectory/myfile.db' asUrl path.

�� "'c/myDirectory/myfile.db'"

"Absolute path /c/myDirectory/myfile.db not OK"

'sqlite3:///c/myDirectory/myfile.db' asUrl path.

�� "'c/myDirectory/myfile.db'"

Adding Slashes

'sqlite3:////////c/myDirectory/myfile.db' asUrl path.

�� "'c/myDirectory/myfile.db'"

Another concern is that garage as it is works in Pharo 3, 4 and 5. Then if we update Zn I'll have to add Zn to my dependencies and load the correct version accordingly, what do you think? (I prefer that to backporting)

Guille��

El lun., 18 de may. de 2015 a la(s) 11:27 a. m., Sven Van Caekenberghe <sven@stfx.eu> escribi��:

Hi Guile,

> On 18 May 2015, at 10:48, Guillermo Polito <guillermopolito@gmail.com> wrote:
>
> Well, I wanted in general to have a single easy-to-learn way to build a database connection string for all drivers.
>
> [driverid]://[host][:port]/[databasename]?[properties]
>
> Then, for sqlite I would like to have:
>
> sqlite3://myDirectory/myfile.db
>
> or
>
> sqlite3://memory
>
> Now, for Garage 0.1 I was using ZnUrl to parse the connection strings and that is not working for urls like the following because if the schema is not 'file' then the parser fails to to transform the port (an empty string in this case for the parser) to an integer
>
> sqlite3://c:/myDirectory/myfile.db
>
> In bleeding edge I am using an alternative parser that does no conversions and allows urls like that one.

I understand the reasoning here, but I would suggest that you at least consider changing your mind. Over time, a lot of work went into ZnUrl, and many people used it and helped fixing many problems. Recently we tried to improve the situation for special schemes a bit (for git URLs). We're not yet there, but you (your use case) could help improving the situation.

I tried to take a principled approach regarding the specs (not that there is one clear spec, haha), but edge cases should still be possible.

Consider the following:

'postgresql://localhost:14433/test-db?username=john&password=123456' asUrl.
'postgresql://john:123456@localhost:14433/test-db?encoding=utf8' asUrl.
'postgresql://localhost/default' asUrl.

'sqlite3:///myDirectory/myfile.db' asUrl.
'sqlite3://memory' asUrl.
'sqlite3:///c:/myDirectory/myfile.db' asUrl.

According to me, these all parse correctly. Of course, ZnUrl does not know or understand what is possibly special about any particular scheme (apart from HTTP(S)). Still, it is just an object that can be manipulated.

The default port can be computed along the lines of #portOrDefault, maybe we could add a #portIfAbsent: ?

Conversion to a file references can be done as follows:

'sqlite3:///c:/myDirectory/myfile.db' asUrl
�� copy scheme: #file; asFileReference.

Which basically reads as: 'I know this is not a file:// URL proper, still I want to interpret it as if it were one'. Maybe we could add a #forceAsFileReference ?

Anyway, you get the idea. You know I am willing to help.

Sven