[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