[openstack-dev] [Quantum] A generic approach for converting DB objects into dictionaries
Avishay Balderman
AvishayB at Radware.com
Fri Jan 18 10:20:38 UTC 2013
Can you please explain why DRY is violated ? And what about the decoration approach I have suggested in the other mail?
At the end of the day we have to declare the mapping info somewhere. So the question is where - right?
Thanks
Avishay
Sent from my iPhone
On 17 בינו 2013, at 23:09, "Mark McClain" <mark.mcclain at dreamhost.com<mailto:mark.mcclain at dreamhost.com>> wrote:
Even with the domain specific mappings in each file, you're still repeating a lot of information which violates DRY (don't repeat yourself) principles. I also think that the ideal solution will probably be more comprehensive and disruptive to a number of the internal APIs.
mark
On Jan 17, 2013, at 4:27 AM, Avishay Balderman <AvishayB at radware.com<mailto:AvishayB at radware.com>> wrote:
Hi
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.
Example:
db_base_plugin_v2.py will hold the mapping for models_v2
Thanks
Avishay
From: Mark McClain [mailto:mark.mcclain at dreamhost.com<http://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.
mark
On Jan 16, 2013, at 8:57 AM, Avishay Balderman <AvishayB at radware.com<mailto:AvishayB at radware.com>> wrote:
Background:
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
Thanks
Avishay
Appendix
MODEL_TO_API_MAP = {
"quantum.db.l3_db.Router":["id",
"name",
"tenant_id",
"admin_state_up",
"status",
{"external_gateway_info":{"gw_port":["network_id"]}}
],
"quantum.db.models_v2.Network":["id",
"name",
"tenant_id",
"admin_state_up",
"status",
"shared",
{"subnets":["id"]},
],
"quantum.db.models_v2.Subnet":["id",
"name",
"tenant_id",
"network_id",
"ip_version",
"cidr",
{"allocation_pools":[{"start":"first_ip"},{"end":"last_ip"}]},
"gateway_ip",
"enable_dhcp",
{"dns_nameservers":["address"]},
{"host_routes":{"routes":["destination","nexthop"]}},
"shared",
"gateway_ip"
],
"quantum.db.models_v2.Port":["id",
"name",
"tenant_id",
"network_id",
"admin_state_up",
"mac_address",
"status",
{"fixed_ips":["subnet_id","ip_address"]},
"device_id",
"device_owner"
],
"quantum.db.l3_db.FloatingIP" : ["id",
"tenant_id",
"floating_ip_address",
"floating_network_id",
"router_id",
{"port_id":"fixed_port_id"},
"fixed_ip_address"
],
"quantum.db.securitygroups_db.SecurityGroup" : ["id",
"tenant_id",
"name",
"description",
"external_id"
],
"quantum.db.securitygroups_db.SecurityGroupRule" : ["id",
"tenant_id",
"external_id",
"security_group_id",
"ethertype",
"direction",
"protocol",
"port_range_min",
"port_range_max",
"source_ip_prefix",
"source_group_id"
]
}
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130118/ed71cb24/attachment.html>
More information about the OpenStack-dev
mailing list