@jamescheney's comment on #966 prompted me to look into places where we parse, use, and reconstruct database arguments strings. To my surprise it turns out each database driver is equipped with its own parsing logic, which smells to me. In each driver the parsing logic is hard-wired into the database connection constructor. I think this should be separated. At the very least the parsing logic should be placed in the parent class database as the logic used by each driver is very similar. More fundamentally, I think the database driver interface is suboptimal. Rather than being directly parameterised by a database arguments string, they ought to be parameterised by the database arguments (i.e. host, port, username, password). This would remove need for parsing within each database driver.
We also reassemble the database arguments into a string in various places, e.g. in lib.ml, page.ml, and value.ml. Each using an ad-hoc logic of their own. This should be consolidated also.
@jamescheney's comment on #966 prompted me to look into places where we parse, use, and reconstruct database arguments strings. To my surprise it turns out each database driver is equipped with its own parsing logic, which smells to me. In each driver the parsing logic is hard-wired into the database connection constructor. I think this should be separated. At the very least the parsing logic should be placed in the parent class
database
as the logic used by each driver is very similar. More fundamentally, I think the database driver interface is suboptimal. Rather than being directly parameterised by a database arguments string, they ought to be parameterised by the database arguments (i.e. host, port, username, password). This would remove need for parsing within each database driver.