Fixes #1358

[SohumB]

Buffer essentially needs handling like a base type, as far as I can tell. That, and isHash should really encapsulate the logic of finding actual hashes rather than JS objects.

[mickhansen]

Could you provide a test aswell? So we don't have regression bugs later :)

[SohumB]

Thanks for the push to do so - and I found another bug while writing the test :p

I'll add a test for the associations pathway I found the bug by in a sec.

[janmeier]

Could you please check that the user matching the buffer is actually returned, and that the data is a buffer?

users[0].binary instanceof Buffer

[SohumB]

AFAIK, the database itself returns the data as a string here. Sequelize would have to check input to binary fields (in .build?) and specifically convert them into a buffer, I think.

[janmeier]

We return data in BLOBs as buffers (https://github.com/sequelize/sequelize/blob/master/test/dao-factory.test.js#L1826), so I just though it might make sense to do the same for BINARY fields. I actually though it was already impemented though :)

The conversion happen in query.js as i recall it

[SohumB]

Judging from a grep of the source code, Sequelize only does a conversion into Buffer for mariadb and sqlite.

[janmeier]

Jup, mysql and postgres handles the conversion automagically :)

[SohumB]

Why is Travis is failing on postgres here? All that it's getting to is declaring the field as a STRING(16, true)...

[mickhansen]

return elem should be enough

[mickhansen]

Postgres must not support STRING BINARY, any experience with this @janmeier ?

[janmeier]

Nope, seems to only support bytea (basically BLOB) http://www.postgresql.org/docs/7.2/static/datatype-binary.html

Must have been missing tests for that :D

[mickhansen]

Guess so. I guess we'll have to wrap the tests for this in != postgres.

[janmeier]

If we do so we should also throw an error, if the user tries to create a binary string column under postgres. Or perhaps just use a bytea column?

In most respects, you can regard a BLOB column as a VARBINARY column that can be as large as you like.

http://stackoverflow.com/questions/8476968/varbinary-vs-blob-in-mysql

The distinction seem to be neglible

[mickhansen]

Hmm good question. Overall we need to decide if we want to make compatability code for stuff like this or just let the user pick the right types and throw errors if not supported. Ideally an ORM should work regardless of the database behind (ofcourse thats utopian but a nice idea)

[SohumB]

A bytea column seems to me to be the best option. The docs do say it's postgres' version of binary strings.

(For my usecase, I'd just use the UUID type :P)

[mickhansen]

@SohumB Want to take a crack at bytea?
If not, please change it so tests are only run for the supported dialects and an error is thrown if attempting to use STRING BINARY with Postgres.

[SohumB]

Done! I think. Found another bug, too - you're depending on this in the specialised QueryGenerators, which sometimes you pass this.something to without binding this.

But yea, done! Probably!

[SohumB]

Wait, hang on. Why are the expect(binaryRetrieved.id).to.be.an.instanceof.string tests passing on postgres, then?

[mickhansen]

@SohumB it is? Some test was failing originally atleast.

[mickhansen]

Looks like solid work. @janmeier mind taking a look too?

[SohumB]

It is now, I mean. The original error was that postgres didn't understand BINARY, then that this wasn't getting bound and so SqlString.escape would use X'' syntax rather than E'\x' syntax. What I'm confused about is that the test appears to return a Buffer object, but for some reason the test that checks that it's an instance of string is passing.

[janmeier]

Jup, looks solid to me as well

[mickhansen]

Tests are green! Let's assume it works! :D