Thanks for taking a look, I'll answer between lines :).
El mar., 12 de may. de 2015 a la(s) 8:35 p. m., Torsten Bergmann <
astares@gmx.de> escribi��:
Hi Guille,
I had a short look at Garage [1]. Nice initiative!
Looks like using a file is not supported for the SQLite3 backend in Garage:
�� ��GADriver fromConnectionString: 'sqlite3://file://C:/temp/test.db'
�� ��GADriver fromConnectionString: 'sqlite3://C:/temp/test.db'
Maybe GASqlite3Driver>>fromConnectionString: could be adopted, but the
conversion to a Zn URL already removes some stuff. (Ab)using the schema in the URL
as a driverID is nice - but prevents the use of file:// schema.
How can one construct a file db?
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.
��
Also I do not understand: while "Garage-Postgres"�� uses the Postgres
project PostgresV2 as a backend the "Garage-Sqlite3" does not use
NBSqlite3 or SQlite3 projects as backend.
Well, the main rationale behind this is that the public APIs of NBSqlite3 and Garage are not compatible while the one of Postgres is. I did not want to insert changes into NBSqlite3 that could break users. On the other hand, I could *patch* Postgres in the first version with some extension methods.
Then, there are some other reasons/problems that bugged me:
�� - I noticed while doing garage that even if the drivers are different in the very end, there are similarities in structure and code between them. And I wanted to reuse that code and put it into only one place instead of duplicate it for each driver, because it is easier to maintain. In that sense the Garage-Core driver is not just *an API* but has a bit of common behavior e.g., streaming of resultsets, some common superclasses.
��
- Garage only needs its drivers to respect the common interface. I'd like to minimize special database features (unless unavoidable). In the case they already exist, I'd not like to publicize them as part of the Garage API because of obvious reasons.
�� - A minor thing but that bothers me nonetheless: An alternative implementation would have been an adapting layer to communicate with the existing driver(s). This looked also as an overkill in maintenance. Also, some drivers such as mysql's was apparently not actively maintained so I would have to maintain a layer of adaptors and the driver itself.��
So "GASqlite3FFI" copies many methods of the original NBSQLite3 project from Pierce and myself
and is therefore like an own fork now.
Also the name FFI is misleading as it uses NativeBoost instead of FFI ...
Yes, it's like a fork now. Maybe we can split it into another package so I can use it in garage easily?
��
Also it would be good if the project would be layered, we could have a
"Garage-Core" and "Garage-Tests-Core" with "Garage-Mysql" and "Garage-Tests-Mysql" for
the fixtures. The idea is always to be able to load runtime code without tests
for production code.
Well, if that is the desire of the majority, we can do it. For the moment I wanted to keep simple the metacello configurations also, so it was my trade-off to not split the packages for simplicity ^^.
��
Thanks, and sorry for the long email,
Guille