Tagged: node.js

Sequelize has less opaque errors

Good news:  sequelize no longer has opaque global leak errors when using mocha:  https://github.com/sequelize/sequelize/pull/1051

The errors are MUCH less opaque and much more relevant to the test failure when watching your tests fail.  For example, when you try to create a model with a column that does not exist in your schema:

Error: SQLITE_ERROR: table articles has no column named ‘new_column’

Which is much more useful than a notification that the library that you’re using is leaking globals.  Yay!

Advertisements

Sequelize has very opaque errors

While trying out sequelize, I was TDD’ing some code using mocha and reached this error from mocha while watching a test fail:

Error: global leak detected: columnTypes

So I looked through the code and found https://github.com/sequelize/sequelize/blob/f16f39221d9f3be64d7fd58235d5420eba4e10be/lib/dialects/sqlite/query.js#L38 which certainly looks like it would be a global leak, since the code is referring to “this” inside of an anonymous function.

However, inside the sequelize tests, “this” was referring to some sort of representation of the query, likely due to an “apply” or “call” somewhere.  Some time later, I just tried to get the test to pass, and once I sync()ed the table and added some columns to the model, it did.

Long story short: that is the error that you get when:

  1. the table does not exist
  2. the model does not have any attributes

Mongoose and unique indexes

When testing a model’s unique index, you may find that your specs do not fail as you would expect.  You may find that the unique index appears to not be taking effect.

If that is the case, you can:

describe(“something unique”, function(){

  beforeEach(function(done){

    model_under_test.ensureIndexes(done);

  });

  it(“fails with an error..”);

});

Another (possibly better) alternative is to make assertions on the model schema.

Faster tests through overriding defaults

I’m using an excellent piece of abandonware called connect-assets on a project.  It works well and does its job fairly well.  It’s a shame that it’s so neglected.

Yesterday I started to get a staging environment up and going on my project.  Connect-assets wants to serve static assets out via hostname.com/js/ and hostname.com/css/ where I normally prefer to serve static assets out via hostname.com/static/js and hostname.com/static/css which results in a simpler nginx config for serving these static assets.

As I looked through the documentation and code for how to do this, I came across a configure option named “detectChanges” that defaulted to “true” which (as near as I can tell) serially and synchronously stat()ed each file involved for every request.

One of the reasons why I’m doing development in node.js/express is because it’s leaps and bounds faster than doing ruby on rails.  My test suite (including integration specs) takes ~3.3 seconds from execution to completion (including compilation, etc.) on my shiny new workstation.  After overriding the default of “detectChanges” my suite takes ~2.6 seconds.

Yay!  🙂