Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a VARBINARY data type #5981

Open
dantman opened this issue May 28, 2016 · 13 comments
Open

Need a VARBINARY data type #5981

dantman opened this issue May 28, 2016 · 13 comments
Labels
dialect: mysql For issues and PRs. Things that involve MySQL (and do not involve all dialects). good first issue For issues. An issue that is a good choice for first-time contributors. P4: nice to have For issues that are not bugs. status: understood For issues. Applied when the issue is understood / reproducible. type: feature For issues and PRs. For new features. Never breaking changes.

Comments

@dantman
Copy link
Contributor

dantman commented May 28, 2016

Sequelize currently doesn't have a native string type that maps to an easily indexable VARBINARY in MySQL.

This is going to be a growing issue due to utf8mb4, under which the practice (that Sequelize also uses) of using VARCHAR(255) and InnoDB leads to indexes that are too large and cause CREATE TABLE to fail. With the new charset limitations, some columns will simply use a smaller index size; while others will be better off using a VARBINARY. For example, a sorted title index would likely be better off with a utf8mb4 index with a smaller size and a column storing the string identifier for a facebook/google/etc... account would be best off switching to a VARBINARY.

Note that STRING.BINARY will not work because that is for VARCHAR(255) BINARY which still use utf8mb4 and just use the _bin charset, they still use 4 bytes per character in indexes. Also BLOB makes for indexing issues, our inherent problem.

Naming ideas: STRING.RAW, VARBINARY

This should be relatively simple for someone who knows how data-types.js works to do. I can't submit a patch set since I don't understand enough about how the oids in the pg data-types.js file works.

@janmeier janmeier added type: feature For issues and PRs. For new features. Never breaking changes. dialect: mysql For issues and PRs. Things that involve MySQL (and do not involve all dialects). good first issue For issues. An issue that is a good choice for first-time contributors. labels Jun 20, 2016
@castarco
Copy link

Not only VARBINARY is needed, we need support for BINARY too.

Both options are far different from VARCHAR and CHAR, since BINARYis treated like an opaque vale, without the risk of encoding-issues.

At our company we're using BINARY to encode our IDs, which are similar to UUIDs... but not the same. And we're using a BINARY column to decrease memory usage.

@Celadora
Copy link

Celadora commented Feb 6, 2017

You can use type: "binary(bytes)" to define a binary column as a temporary solution until this feature is done.

@jorrit
Copy link
Contributor

jorrit commented Jun 2, 2017

Wouldn't STRING(num).BINARY be the right data type to map to VARBINARY in MySQL? It seems dialects/mysql/data-types.js doesn't do anything with the BINARY part yet.

@stale stale bot added the stale label Aug 2, 2017
@stale
Copy link

stale bot commented Aug 2, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, just leave a comment 🙂

@dantman
Copy link
Contributor Author

dantman commented Aug 3, 2017

We still need a proper way to use varbinary.

@stale stale bot removed the stale label Aug 3, 2017
@rodriamaro
Copy link

We need it

@vmadman
Copy link

vmadman commented Sep 5, 2017

+1

I will look into adding it, if I can, but I suspect that it is more complicated than meets the eye... given that no one has taken this on already.

Edit:

After a small amount of investigating, it really doesn't seem all that important, since Sequelize doesn't do much with the type, anyway. There might be some advanced reasons to need the data type, but, on the surface, it doesn't seem like it would give you very much.

I found this...

@DalfDev
Copy link

DalfDev commented Jun 17, 2019

+1

@papb papb added P4: nice to have For issues that are not bugs. status: understood For issues. Applied when the issue is understood / reproducible. labels Aug 17, 2019
@hilary138
Copy link

After a small amount of investigating, it really doesn't seem all that important, since Sequelize doesn't do much with the type, anyway. There might be some advanced reasons to need the data type, but, on the surface, it doesn't seem like it would give you very much.

I found this...

* [Stack Overflow: sequelize-js-how-to-map-a-varbinary-type-from-mysql](https://stackoverflow.com/questions/13888689/sequelize-js-how-to-map-a-varbinary-type-from-mysql)

* **See also:** [Source: data-types.js](https://github.com/sequelize/sequelize/blob/master/lib/dialects/mysql/data-types.js)

That's an easy workaround, but it's nearly useless to the average user if it's not documented.

@Benjamin-Willard
Copy link

+1

@WikiRik
Copy link
Member

WikiRik commented Mar 17, 2022

@ephys maybe this would be a nice addition to sequelize/website#11 ?

@ephys
Copy link
Member

ephys commented Mar 17, 2022

Done :) I've documented how to use raw sql types in sequelize/website#11:

image

I think we should also support this DataType natively

@WikiRik
Copy link
Member

WikiRik commented Mar 17, 2022

Done :) I've documented how to use raw sql types in sequelize/website#11:

image

Thanks!

I think we should also support this DataType natively

Native support would indeed be nice. If somebody reads this and wants to implement it, feel free to make a PR for this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialect: mysql For issues and PRs. Things that involve MySQL (and do not involve all dialects). good first issue For issues. An issue that is a good choice for first-time contributors. P4: nice to have For issues that are not bugs. status: understood For issues. Applied when the issue is understood / reproducible. type: feature For issues and PRs. For new features. Never breaking changes.
Projects
None yet
Development

No branches or pull requests