Closed gernest closed 6 years ago
I love making it easier to extend the list of drivers and not hard code things here, however, I consider the db/sql registration method to be an anti-pattern. It requires global variables, init functions, and blank imports, all of which I dislike.
I'd much prefer if there was no init function and no global registry of databases. Much better just to have a boring function that just returns a list of types constructed from each driver package.
I can understand why you like it this way! Scraping the magic init and registration the driver interface is useful.
I was thinking about #7 . That way it is easy to mock the driver interface with a dummy database.Info
and have nice tests, this can apply to other commands as well
@natefinch init, global vars are gone. I compose the drivers from their respective packages. Is this worthy the effort?
If there is any chance of merging the changes let me know so we can save time. I am happy to make changes though if they will be of any help to the project
@natefinch done!
@natefinch Done!
Add database/sql like driver API
This refactors the API for adding drivers . The inspiration is from the
database/sql
. There is a global driver registry inside thedrivers
package, that takes care of storing and retriving drivers.This brings flexibily for support for more databases since the implementors just need to conform with the interface. This is just the minimun initial API I came up with, we can add more mothods as we seem fit.
drivers.Templates
I was planning to allow each driver to handle which templates to generate with the
gnorm init
command.I mean something like
gnorm init postgres
will result into sane default templates for postgres that a user will eventualy fine tune if they want to to fit their needs.I was afraid If I omitted this interface I might forget about it. We can remove it, since I might implement driver specific init templates in a separate PR where this interface is crucial.