[openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants
Henry Gessau
HenryG at gessau.net
Mon Oct 17 10:56:40 UTC 2016
Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> 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?
OK, I suppose using *_FIELD_SIZE constants from neutron-lib in the alembic
scripts is safe enough.
I began thinking about this problem before I added field sizes to neutron-lib,
and it was not a matter of trust. It was more about having a mechanism to
detect a problem if someone tries to change, say, FILE_NAME_MAX_LEN from 16 to
80 without realizing it is related to a DB field. That's a hypothetical
example, but we have many constants and I did not want to count on humans to
detect every impacting case.
More information about the OpenStack-dev
mailing list