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

Reply via email to