Major Refactors

In order to address a variety of small issues, I think sql-bricks needs a significant refactor. I want to reduce the line count, but more importantly, I want to reduce the complexity. SqlBricks is no longer as “easy to understand & debug” as it claims to be.

• Make SqlBricks namespace a function or class, so you have to call SqlBricks().select instead of SqlBricks.select (or var select = require('sql-bricks')().select;). This way you can set the default options, like SqlBricks({placeholder: '?%d'}) (#91) and that way extensions won’t need to pollute the global namespace to change things like sql.conversions (#62).
• replace the _extension/subclass/inherits/applyNew stuff with basic prototypical inheritance & restrict the way SQLBricks can be called (throw an error if it’s called with or without new, depending on whether it’s required)
• remove the defineClause/mini-templating language #100
• remove the placeholder-replacing code
• reduce the variety of ways things can be called (values as an array, object vs separate args, insert() vs insert.into() vs split_keys_vals_mode). Have one right way, thus reducing the API surface area & making the lib shorter, simpler & more maintainable
• (possibly) support named parameters (#91)

While we’re at it, we might as well fix the outstanding bugs & issues, but I don’t want those to necessarily slow down the refactoring. It might be better to split the refactoring into pieces and do them separately over time, but I’d like to release it as one big 3.x rather than multiple backwards-incompatible releases.

Oct 2017 Update:

Looking through the capabilities and the code, I think there must be a cleaner, more generic way to go about this. I suspect that the important parts of this library can be implemented in 100 or 200 lines of code instead of ~1k. Drop the “mini” templating language and the subclassing/inherits. Probably be a little more rigid in what kinds of input the methods accept. Use JSON to define all the clauses (and their order) and what kinds of input they accept. It may make sense to template strings, but if so it should be a one-line regex, not a mini-templating language. Allow extension in a simpler way: by allowing consumers/libraries to directly swap out methods or metadata, like Backbone.ajax/sync. The toParams() parameter substitution code is quite hairy (auto-numbering, etc); we probably need to tighten up the scope and disallow certain things there.

Mar 2022 Update:

I renamed this Issue from “3.0 Refactor” to “Major Refactors”, since I decided to go ahead and ship v3.0 with only one of these (remove the defineClause/mini-templating language #100), along with the removal of the Underscore.js dependency. I would still like to tackle some of these, especially the Oct 2017 idea of simplifying the library dramatically, but I don’t have much motivation to do so, since I don’t use this library often (in most cases I think it’s better to write the SQL directly).

[prust]

@paleo: FYI, I added a reference to “A Layer Above Database Connectors” to the readme in 9663defe67 – feel free to issue a pull request if you’d like to update it in any way.

[paleo]

Could you consider switching to TypeScript and to a modern JS instead of ES5 / Underscore?