Open Stack

I would avoid trying to make special functions that are meant for everyone
to use to interact with the standard attribute table. There are a wide
variety of use cases (1:1 relationships, 1:M relationships, stuff visible
in the API, stuff internal to Neutron, etc) and trying to guess how they
will look now will not work.

So for now just work on implementing the timestamp by interacting with the
model like any other new relationship (e.g. model.standardattr.created_at).
You might be able to use callbacks for this if it makes it easier, but
don't start out by over-engineering something meant to be generic for all
standard attributes.

>if plugin enable/unable several times and create some resources during the
change,

Why would a plugin add support for the timestamp extension, remove it, and
then re-add it?

On Sun, Dec 13, 2015 at 1:37 AM, zhaobo <zb4515 at 163.com> wrote:

> Hi guys,
> Could you give some good ideas about add neutron common attributes into db
> table 'standardattributes'? Like timestamp, it must be a common one should
> be added.
> The table 'standardattributes' is imported from [1]. It must be neutron
> common attrs should be added into this table in the future.
>
> Now I had find a way to add timestamp based on subscribe/notify through
> defining a new subscribe resource named 'standardattr'.
> The code is [2][3]. I use this way as garyk is moving the extension
> resource from base code(db_base_plugin_base / db_base_plugin_v2 )to
> extension. I realize it will not be allowed to modify the code in base
> anymore. So I decide to add a mechanism into base code for not add the code
> when every new attribute addition, if we want to add other attributes into
> this table, we just fulfill their own field addition functions into db
> model. If my thought is reasonable, please add review list into [2][3].
>
> Original, I just think I could set/get common attr through
> db_model.standardattr.(which column I had added into table and models/) ,
> more details like network_model.standardattr.created_at/updated_at. I had
> made it in the patches [3] before. So I still have doubt about whether my
> way is correct or make it difficult. I wish your kind help and guidance.
>
> If there is some doubts of mine, please feel free to correct. I'm now
> still feel whether my way is right or can be accept by our community. If my
> way is too complex and useless, which way should I follow? Could anyone
> give your kind suggestions? Thanks.
>
> And one more question:
> I think make timestamp as extension is good, but there are some problem
> when use it.
>
> 1. As this bp will expand the tables in db of neutron core resources,
> whatever users use a plugin which support timestamp or not, db will still
> store the related data.
> -------My reason is: At first , if a plugin unable the timestamp and won't
> store data into db,  but when this plugin support this plugin once, db
> become to store timestamp.
> -------This may cause issue about how to set the timestamp to the original
> data, if plugin enable/unable several times and create some resources
> during the change,
> -------the db will contain some strange data, and when the plugin support
> timestamp at last, users will be confused why the resources created during
> the period of unable timestamp don't have the correct timestamp.
> -------And it will cause some strong behaviors, like users create the base
> resource for a long time, why it doesn't have timestamp when it is true to
> open the timestamp.
> 2.Like the bp of mtu, I remember this field of network is as the neutron
> core attribute of network in the beginning. Now it had been moved to
> extension, and the field of mtu still be stored into db whatever plugin
> support mtu or not.
> 3.Like nova and other modules , the timestamp is treated as core attribute
> of resources, like instance, action list and so on. Neutron treat it as
> extension, so I think this timestamp of neutron should be drawn towards the
> usage of other modules.
> 4.For other reasons, we can request the incremental query based on
> timestamp, when the scale is large, and there are so many messages or
> resources in system, no one want to list the info through get all of them.
>
> So I have doubts about whether timestamp fields should be stored into db
> whatever the plugin support timestamp or not. When plugin support it, users
> could see them in the returned info. Wish your kind suggestion to help me
> to move on the timestamp. Thanks.
>
> [1] https://review.openstack.org/#/c/222079/
> [2] https://review.openstack.org/#/c/251193/
> [3] https://review.openstack.org/#/c/213586/
>
>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151213/b7ce618f/attachment.html>