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 >> 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
