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

[Ola Thoresen]

>>
>
> Oddly enough, nobody has any opinions. Come on, stating that we have
> been doing that right is also a good feedback.
>



I don't have any strong opinions, and I have not read the code, so I 
might be wrong, but I have a few questions which might lead to others 
having opinions.

a) Are you limited to just two parts in the schema version numbering?
- To me it makes sense to use a two part ("two digit") version for the 
releases, and use another number for intermediate versions.  So kea 1.0 
is released with schema x.y and all updates to the schema until the next 
release is numbered x.y.z
This will not bloat the schema version too much, as all the minor 
updates don't count as soon as a new version of kea is released.

b) Is there an effort going on to synchronize the schema versions 
between the different db-platforms?  The difference between IE pgsql and 
mysql should not be THAT big - and that PG is using schema version 3 and 
MySQL is already in version 5 looks a bit strange to me.
The schema version should reflect the actual contents of the schema 
(what columns and indexes and so on that they contain) and if they are 
more or less "on pair" between the DBs the version should also be more 
or less the same.
- Of course, it can be that PG is lagging behind MySQL (I have not read 
the code) but this sounds like an issue that should be prioritized, as 
working with code that needs to behave vastly different based on what 
DB-engine is running in the background sounds like a big problem in the 
long run.


Rgds.

Ola Thoresen