Jump to: navigation, search

Db-string-type-cleanup

Blueprint Name: db-string-type-cleanup

Author: Rick Harris/s1rp/sirp <rconradharris@gmail.com>

Summary

The proposal here is to change from using SQLAlchemy's String type directly in our models to using logical datatypes that may or may not (depending on the database) map to string columns under the hood.

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. With the proposed change, however, typos become parse-time errors that we can promptly fix.
  • 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). With the proposed change, developers are encouraged to use the existing logical datatypes where it makes sense, and only introduce new datatypes when necessary.
  • 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.). With the proposed change, we are free down the road to change the underlying representation of these logical datatypes where it makes sense.

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 nova/db/sqlachemy/types.py module.

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

Count Current Physical Datatype Proposed Logical Datatype
1 String(2047) types.SMBackendConfigParams
2 String(12) types.PCIAddress
2 String(5) types.NetworkProtocol
2 String(8) types.PCIDeviceType
4 String(4) types.PCIVendorID, types.PCIProductID
5 String(39) types.IPAddress (exists)
7 String(256) types.String
8 String(43) types.CIDR (exists)
56 String(36) types.UUID
388 String(255) types.String