objection-db

Objection.js ORM layer -> FoodBoss DB

Environment Variables

You should create a .env file in your directory that defines DB_CONNECTION_STRING - set the value to our staging DB string, not prod!

Comparing Sequelize and Objection.js

Doing a select query that includes a binding, coalesce, and an alias for the column name:

Using raw/literal:

person.findAll({ 
  attributes: [
    'name',
    [
      sequelize.literal(
        sequelize.query('COALESCE(sum(?), 0)',
          {
            replacements: ['age'],
            type: QueryTypes.SELECT
          },
        ),
      ),
      'childAgeSum',
    ],
  ],
});

const childAgeSums = await Person.query().select('name', raw('coalesce(sum(??), 0)', 'age').as('childAgeSum’));

Using built-in coalesce function:

person.findAll({
  attributes: [
    'name',
    [ 
      sequelize.fn('COALESCE', sequelize.fn('SUM', (sequelize.col('age'))), 0),
      'childAgeSum',
    ],
  ],
});

const childAgeSums = await Person.query().select('name', fn.coalesce(fn.sum(ref('age')), 0).as('childAgeSum’));

Where the schema lives

• Sequelize: they are defined in models/* files, but they aren’t used until we do some overhaul, because the knex migrations are current source of truth. Have to be careful not to run the migration
• Objection: Existing knex migrations are retained, can optionally add jsonSchema to models/* for validation

Relations:

• S: usage of foreignKey can get confusing, switch from hasMany to belongsTo, etc.
• O: more explicit, with naming of table.foreignKey convention
• S: writing just one foreignKey entry is quicker
• O: don’t need to define a model class for CategoryResto, but can