Open Stack

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> 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] 
> 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> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
> _______________________________________________
> OpenStack-dev mailing list
> 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/20130117/6a182cd0/attachment.html>