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?
Ihar
__________________________________________________________________________
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
