Join GitHub today
Added a NOW() helper #372
It adds a
Includes one DB-specific override, that was brought up as an example in #310, for SQLite3 that replaces
So is the main driver of this for schema creation, or being able to use a cross-database method for
If it's only for schema creation, it'd probably be cleaner to check the type of the column being created and then allowing a whitelisted set of
If it's for use anywhere, then it might be cooler to go all-out and do something like
knex.moment.now() knex.moment.currentDate() knex.moment.currentTime()
...and then this could serve as the foundation for normalizing behavior for common date helpers cross-db:
Main driver for me is for use in queries – in WHERE clauses and as values in UPDATE and INSERT.
I like the all-out approach – my initial proposal, voxpelli@1f3642b, included a mechanism for extending this to not just date helpers, but to all kind of simple helpers, so that one only has to use knex.raw() for the most complex cases and can use these methods for ordinary simple methods.
To eg. have a mechanism for expose math and string functions through as well could be useful. Possible variations could look like:
Okay, now that I think about it, this is actually a pretty neat approach. I think I was initially put off by the verbosity of it, but maybe if we did
Also, I just pushed a commit for using getters for lazy-loading the migrate / schema stuff more cleanly. Want to just follow that pattern for the function piece and re-open the PR with the original approach, and we can any discuss implementation details from there.