Resolve logic duplication in the db.types namespace

[dmos62]

Problem

@mathemancer pointed out that some of the logic in db.types.base::_build_db_types_hinted is a duplicate of logic in db.types.operations.cast (see global variables TEXT_TYPES and NUMBER_TYPES). Specifically it's the logic that describes which types are string-like and which are number-like. This suggests that we could centralize this logic.

Proposed solution

Not totally clear. A new file in the db.types namespace that would hold lists of database types, each list grouping types according to some attribute, like them being string-like or number-like.

A slight complication is that the db.types.base method expects those types to be expressed as Enum instances, while db.types.operations.cast expects them to be type ID strings. You could say that the former wants to convert from Enum to string as late as possible, while the latter as early as possible.

[dmos62]

A slight complication is that the db.types.base method expects those types to be expressed as Enum instances, while db.types.operations.cast expects them to be type ID strings. You could say that the former wants to convert from Enum to string as late as possible, while the latter as early as possible.

@mathemancer I think we could use a convention for how to deal with Enum instance values, or, rather, whether to convert an Enum instance to its value early or late. I've been doing it one way and you another and now we're having interop problems. Maybe a quick sync call at your convenience?

[dmos62]

This discussion came of the above suggested sync call: #1184

[dmos62]

Resolved in #1222