4 ms·
Kudos, gorgeous. Would be great to have a generic version that can also connect to other databases too. Perhaps this is the start of an async interface that c
by willvarfar 5y ago
Kudos, gorgeous. Would be great to have a generic version that can also connect to other databases too. Perhaps this is the start of an async interface that can be used instead of dbapi?
One thing that stood out was the overloading of using functions sometimes and sql snippets other times. For example,
.select('column').where('id', 1).where('name', 'Tom')
or
.select('column AS alias').where('id = ? AND name = ?', 1, 'Tom')
This means the framework has to pass through the snippet as-is, rather than applying escaping etc.
Although sql injection is usually through values, it can be through other parts of the string too, e.g. in many user query builder UIs the column names themselves may be tainted.
I'm generally a fan of all or nothing, e.g. either go with building your own string, or else use helper functions for everything e.g.
.select('column').as('alias').where('id').equals(1)...
This means the framework can always correctly escape column names etc.
I ran into problems like this when doing an InfluxDB connector for Presto. The Influx Java client library mixed this up so it couldn't sanitise column names. I ended up just writing my own query builder.
- aforwardslash 5y agoShameless plug - you can have a look at my pet project https://github.com/oddbit-project/rick_db; https://github.com/oddbit-project/rick_db; Its explicitly not async, but the query builder is detached from the DB querying logic, and can be used separately.