rockdai / sql-bricks

Transparent, Schemaless SQL Generation
http://csnw.github.io/sql-bricks
MIT License
213 stars 25 forks source link

Add overrideable identifier preparation methods #124

Open ClaireNeveu opened 4 years ago

ClaireNeveu commented 4 years ago

I'm using sql-bricks in my library and I'd like to add support for automatically converting between snake_case and camelCase.

I've added two overrideable methods on sql: sql._prepareTableIdentifier and sql._prepareColumnIdentifier. By overriding these you can change the behavior of the auto-quoter or simply hook into that pipeline and then pass the identifier on. This is a global mutation which isn't ideal but it's the best we can do with the current state of sql-bricks.

I know there's rumblings about a rewrite that would make it easier to override via inheritance, but since that is a way off I think this would be an acceptable interim solution.

Matching issue: https://github.com/CSNW/sql-bricks/issues/101

prust commented 4 years ago

Thanks for contributing this, @ClaireNeveu! I'll have to make some time to look at it in more detail.

One thing I noticed is that it seems to allow SQL functions to be used directly, where column names are expected -- I think sql-bricks previously required them to be wrapped in sql('...'). Allowing them to be passed in directly like this, with no wrapping, would be nice.

The rewrite does seem to be a long way off, as I haven't had much need or motivation to work on it and my attention has been consumed with other projects. An interim solution like this does seem like a good idea.

ClaireNeveu commented 4 years ago

Sql bricks currently allows you to do select('count(*)').from('my_table') without wrapping the functions and that is actually how the docs recommend you use functions. I just check if what's being passed is a function and exclude that from any potential overrides

In my library I actually add an extra layer requiring you to do select(fn.count('*')).from('my_table') because I differentiate between columns and functions at the type level, but I wasn't planning to push that upstream.