[openstack-dev] [Quantum] A generic approach for converting DB objects into dictionaries

Avishay Balderman AvishayB at Radware.com
Thu Jan 17 08:23:03 UTC 2013

Hi Mark
I am not sure I understand your point.
Is it the fact that the configuration block is "far" from the db class definition?
If this is the case - how about having a decorator that will handle the serialization ?
@api_as_dict(inc =["id","name","tenant_id","admin_state_up","status","shared",{"subnets":["id"]})
class Network(model_base.BASEV2, HasId, HasTenant):
    """Represents a v2 quantum network."""
    name = sa.Column(sa.String(255))
    ports = orm.relationship(Port, backref='networks')
    subnets = orm.relationship(Subnet, backref='networks')
    status = sa.Column(sa.String(16))
    admin_state_up = sa.Column(sa.Boolean)
    shared = sa.Column(sa.Boolean)

With this approach the serialization is actually on the DB class definition.



From: Mark McClain [mailto:mark.mcclain at dreamhost.com]
Sent: Wednesday, January 16, 2013 10:14 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum] A generic approach for converting DB objects into dictionaries

While it does make sense to move serialization closer to the models, I'm -1 on this particular approach.  The proposal increases the repetitive code by adding yet another place we must modify when changing the model or API.  We should be heading towards something that satisfies the DRY principle.


On Jan 16, 2013, at 8:57 AM, Avishay Balderman <AvishayB at radware.com<mailto:AvishayB at radware.com>> wrote:

When a read operation is preformed via quantum API the result of the DB query is converted into python dictionary.
So we  have a function like this for each DB entity:

    def _make_router_dict(self, router, fields=None):
        res = {'id': router['id'],
               'name': router['name'],
               'tenant_id': router['tenant_id'],
               'admin_state_up': router['admin_state_up'],
               'status': router['status'],
               'external_gateway_info': None}
        if router['gw_port_id']:
            nw_id = router.gw_port['network_id']
            res['external_gateway_info'] = {'network_id': nw_id}
        return self._fields(res, fields)

A generic approach:
The idea is to have ONE "as_dict"  function that will get the DB object plus meta data that explains how to "dict it".

What we gain here:
1.       We have the mapping of the DB objects to dicts in one central location (See  the Appendix below)
2.       All "_make_XYZ_dict" functions are gone and no need to write them in the future

So we created this configuration and a generic function that does the "magic".
We have also created 9 unit tests  that use the current quantum as_dict functions in one hand and the generic as_dict function on the other hand.

Code is here:
https://www.dropbox.com/s/d9qx16r6ocp4veo/db2dict.py (please ignore alignment issues - the code needs cleanup)

You can actually run it - just put it under quantum/db





  "quantum.db.l3_db.FloatingIP" : ["id",
  "quantum.db.securitygroups_db.SecurityGroup" : ["id",
  "quantum.db.securitygroups_db.SecurityGroupRule" : ["id",


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130117/95d5af64/attachment.html>

More information about the OpenStack-dev mailing list