Open Stack

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  
> FOO_MAX_LEN)
> 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?

Ihar