Difference between revisions of "Db-string-type-cleanup"

Revision as of 16:33, 23 October 2013

Blueprint Name: db-string-type-cleanup

Summary

Rationale

We use string columns to store a variety of logical datatypes: UUIDs, IP addresses, generic strings, among others.

The current practice is for developers to use SQLAlchemy's `String` datatype directly and specify the desired length each time, e.g. String(255), or String(36).

This has a few problems:

• Typos - For example, https://review.openstack.org/#/c/39296 accidentally changed '255' to '25'. Since these are runtime and not parse-time errors, they are usually difficult to recover from and require further cleanup migrations.

• Unecessary Variance - For example, we have 'String(256)' in places where String(255) was preferable (since that's the de facto standard for generic strings)

• No Physical Storage/Logical Datatype Abstraction - Some databases support certain logical datatypes natively, like UUID. By declaring the columns as strings, instead of say 'UUID', we're tying that column down to a particular underlying storage type. (In fact for IP Addresses and CIDR addresses, we're already using this abstraction.)

Design

The proposal here is to extend the work we did for `IPAddress` and `CIDR` to other logical datatypes that are stored as underlying Strings.

This would mean that instead of developers using SQLAlchemy Strings directly and specifying a length, they would use (or add) a predefined logical datatype from our existing sqlachemy/types.py module.

The following mapping from existing physical datatype to logical datatype is proposed: