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 <
s...@stfx.eu> escribió:
> Hi Guile,
>
> > On 18 May 2015, at 10:48, Guillermo Polito <guillermopol...@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
>
>
>
>
>
