[kea-dev] Kea's database schema versioning in practice

[Richard J. Letts]

> -----Original Message-----
> From: kea-dev [mailto:kea-dev-bounces at lists.isc.org] On Behalf Of Marcin
> Siodelski
> Sent: Friday, August 26, 2016 7:55 AM
> To: Kea Dev List <kea-dev at lists.isc.org>
> Subject: [kea-dev] Kea's database schema versioning in practice
> 
> Hi All,
> 
> I am soliciting feedback about the issue raised during review of Kea ticket
> http://kea.isc.org/ticket/4562.
> 
> Kea is using switchable lease/host database backends. The database
> schemas constantly evolve as we add new features which use those
> backends. As an example, in Kea 1.1 release we're significantly expanding
> support for Host Reservations. We have added support for reserving DHCP
> options per host, reserving DHCPv4 message fields like next server, boot file
> name (for PXE boot) etc. In PostgreSQL we have created host reservations
> from scratch since Kea 1.0.


> Kea 1.1 will be released with MySQL schema version 5.0 and PostgreSQL
> schema version 3.0.

The schema versions should be the same at a release; having different version numbers for different backends raises questions about compatibility that you will have to waste time addressing.

> During the development of Kea 1.1 we made extensive changes to the
> schemas but these changes didn't all appear at once. ...
>  If he took some later revision of
> Kea, he could observe that the schema number didn't change but the
> schemas were actually updated, and so on.
I don't think this was a good idea

> So the policies required seem to be:
> 
> - Should we bump up schema versions and update schema upgrade scripts
> every time we commit the change to master? 
Yes
Bump the minor version number throughout development as the schema changes, and then bump to the major.0 on release
> - What does it mean a major change to a schema? In other words, in what
> cases we need to bump up major version number vs minor version number?
A release.
There may be no changes between 4.last and 5.0 but that is better than developers being on some vague version in between and not knowing if they have a schema issue or something else.

(was on vacation)

/RjL