Overhaul type parsers

[felixfbecker]

Prerequisite for #6290
@janmeier Can you do this? I think it's your code

Library support:

• pg: connection-level, reference: Added per-client type parser overrides. brianc/node-postgres#679
• mysql: query-level, reference: https://github.com/mysqljs/mysql#type-casting
• tedious ?
• sqlite ?

The benefit of query-level type parsers are that parse() can be an instance method of the data type.

[felixfbecker]

@janmeier How are data type parsers set in tedious and sqlite?

I would really like to make parse() an instance method of the data types for consistency, so they can access this.options and to have specific parsers per column (for example in one column the JSON should be parsed as one specific class, in the other column it should be a different class). But that is not possible with connection level parsers. The solution would be to handle the data type parsing in sequelize itself, eg take the value from the library and convert it again. This might actually simplify the code.

Raw queries would return the raw values from the library of course.

[janmeier]

sqlite https://github.com/sequelize/sequelize/blob/master/lib/dialects/sqlite/query.js#L167-L181
mssql https://github.com/sequelize/sequelize/blob/master/lib/dialects/mssql/query.js#L91-L105

I definitely see the benefits of tying the data type parse directly to models, since we would be able to do a lot more.

I do however think it might be a problem if we don't also hook into raw queries. For example, dates are not even date objects in sqlite by default.

sequelize/lib/dialects/sqlite/data-types.js

Line 38 in e0e2172

return new Date(date); // We already have a timezone stored in the string

.

I definitely agree that a type system tie up to models would be more powerful though. And if we provide the option of passing the model to a raw query and using the type parsers from the, it might be a good compromise

[felixfbecker]

Yes, we need to take raw queries into account. But stringify() is already a prototype method of the data type, so how are raw INSERT queries handled at the moment? Calling DataType.prototype.stringify()? Then we could certainly do that for parse() aswell, we just have to make sure that options is set on the prototype with some sane defaults.

[janmeier]

Currently raw inserts are handled by sql-string - As you've seen we already call out to datatypes a couple of places from there

[felixfbecker]

I guess it's fine as long as we have options defined on the prototype. So basically do we agree on

• removing parserStore
• making parse() an instance method
  ?

For the postgres parsers I propose we just leave them at the default and then call our parsers on top of it.

[janmeier]

Sounds good to me :)

[felixfbecker]

nice, if you take these, I will do the custom type parsers.