On 17 February 2015 at 03:31, Alexander Tivelkov <ativel...@mirantis.com> wrote: > Hi Client, > > Thanks for your input. > > We actually support the scenarios you speak about, yet in a slightly > different way. The authors of the Artifact Type (the plugin > developers) may define their own custom field (or set of fields) to > store their "sequence" information or any other type-specific > version-related metadata. So, they may use generic version field > (which is defined in the base artifact type) to store their numeric > version - and use their type-specific field for local client-side > processing.
That sounds scarily like what Neutron did, leading to a different schema for every configuration. The reason Clint brought up Debian version numbers is that to sort them in a database you need a custom field type - e.g. http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/database/schema/launchpad-2209-00-0.sql#L25 . And thats quite a burden :) We've had fairly poor results with the Neutron variation in schemas, as it tightly couples things, making upgrades that change plugins super tricky, as well as making it very hard to concurrently support multiple plugins. I hope you don't mean you're doing the same thing :) -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev