Open LoveAndCoding opened 7 years ago
With the query queue working, could the .fn
& .col
methods be just no-ops? I'm thinking this would keep things simple.
@jagged3dge A lot of these are likely to be no-ops at the end of the day since we don't actually need to do any transformations or escaping for any actual DB queries. But for each I need to go through the API and the code from Sequelize and make sure things are mimicked in a way that makes sense. I want to make sure there is as much parity as possible with Sequelize, even with stuff under the hood, whenever I can.
I want to make sure there is as much parity as possible with Sequelize, even with stuff under the hood, whenever I can
Of course. For now, I've forked this and added no-ops for .col
and .fn
for my use. Thanks for your insight :+1:
The Sequelize object is not mocked out very completely yet. It's got only a select few APIs actually mocked properly. Need to define all the functions that I'm able to mock in the core functionality.
API Calls Remaining
.getDialect
.getQueryInterface
.define
.model
.isDefined
.import
.query
.set
.escape
.createSchema
.showAllSchemas
.dropSchema
.dropAllSchemas
.sync
.truncate
.drop
.authenticate
.fn
.col
.cast
.literal
.and
.or
.json
.where
.transaction