Case sensitivity in model queries about epilogue

[mbroadst]

@treefort you're right, and I thought I could just change "like" to "$iLike" here, but it fails on a few tests. Unfortunately that's about all the time I have these day 😄, any interest in trying to figure this one out? PRs are gladly welcomed

[treefort]

The operator could be passed in has an optional attribute in the search options. ex:

var users = rest.resource({
    model: User,
    endpoints: ['/users', '/users/:id'],
    search: {
      param: 'searchOnlyUsernames',
      attributes: [ 'username' ],
      operator: '$iLike'    // (defaults to 'like'
    }
});

It's not pretty, but it'd work... plus it wouldn't mess up existing implementations. I can put it in a PR with corresponding tests and stuff, but I wanted to get your thoughts first.

[mbroadst]

@treefort I wouldn't be against it, but we should also conform with the docs right? (as in default to iLike). I know this seems sinfully lazy, but I can't even recall what tests broke - did you take a look?

[treefort]

Basically, any test that uses a substring match failed. If I'm understanding this correctly, sequelize isn't guarding against the fact that iLike is only supported in pg... so it seems like a strange default. Here's how I tested:

User.findAll({where: { username: {$iLike: "%e%"}}})

which resulted in...

Unhandled rejection SequelizeDatabaseError: SQLITE_ERROR: near "ILIKE": syntax error

[mbroadst]

aah yeah of course, and mysql does case insensitive searches by default as well as sqlite. Yeah okay, please go ahead and add the operator for pg!

[treefort]

Awesome. Addressed with #78.