Open Stack

I just want to add my two cents on this.  Several months ago I asked to nova community about a bug that they decided to don’t implement, this bug was suggesting to add a validation to String OVO field[1] to check if the length of the columns has been changed, the answer was that they considered hard to track those DB changes.  I mentioned this because maybe we can explore this other alternative, just in case that we don’t have the same type of restrictions that nova has. By other hand, if our goal is ensuring that integrity of the class maybe we can validate them as we do in OVO, using a hash code.

[1] https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L254-L265





On 10/15/16, 2:36 PM, "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.
>
>If there are no objections, I intend to submit a patch or patches to:
> - replace constants with numbers in existing migrations
> - ensure all models use the appropriate constants
>
>Existing code uses FOO_MAX_LEN in a lot of places. In most of these places it
>would make sense to simply switch to using FOO_FIELD_SIZE. However, some code
>may be quite far removed from the DB and would look better by sticking to
>FOO_MAX_LEN. I added item 3. above to allow for that.
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev