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

Avishay Balderman AvishayB at Radware.com
Thu Jan 17 09:27:22 UTC 2013

Another thought.. maybe your concern is that the MODEL_TO_API_MAP example that I gave below contained DB objects from various "domains" (l3_db,models_v2,securitygroups_db) and you think that my intention is to have only one mapping that will serve all quantum DB objects. The mapping below just reflected the unit test I have created. You can have a separate mapping for each domain and include it in the same module that handle the API to DB and DB to API functinality.
db_base_plugin_v2.py will hold the mapping for models_v2



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/7823f969/attachment.html>

More information about the OpenStack-dev mailing list