[openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

Ihar Hrachyshka ihrachys at redhat.com
Mon Oct 17 08:25:24 UTC 2016

Henry Gessau <HenryG at gessau.net> wrote:

> Hi neutrinos,
> In Neutron many attributes are stored in database fields. The size of these
> fields therefore determines the maximum length of the attribute values.
> I would like to get some consistency in place around how we define the
> constants and where they are used. Here are my thoughts...
> 1. Raw sizes in alembic migrations
> In the alembic migrations which build the DB schema, we should use the raw
> number value of the field size.
> 2. FOO_FIELD_SIZE in the sqlalchemy models
> In the sqlalchemy models, we should use the <field>_FIELD_SIZE constants
> defined in neutron_lib/db/constants.py
> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like  
> based on FOO_FIELD_SIZE.
> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
> that verify that the models match the schema generated by migrations. If  
> both
> the models and the migrations use the constants then the tests would not
> detect if a patch changes the constant value.
> By using raw numbers in migrations, together with our rule of not allowing
> changes to existing migrations, we allow the tests to detect and fail on  
> any
> attempt to alter a FIELD_SIZE constant.
> Let me know if this makes sense or if you think it's a terrible idea.

Not sure. I mean, if you envision that a ‘constant’ value maintained in  
neutron-lib may be changed in the future, then it’s not safe to use it  
anywhere, both in models and alembic scripts.

But I believe those lib constants are supposed to be unchanged, and  
reviewers of the library should understand that; in which case we should be  
safe to use them in alembic scripts too.

Is it that we don’t trust neutron-lib core reviewers to follow the rule?


More information about the OpenStack-dev mailing list