Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Henry Gessau <hen...@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?

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.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to