OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] key_schema in TOSCA 1.3?


Hi,

 

I think this is a well-known usage of how to do pair definition in a list, so we donât need to have it in the spec.

 

BR,

/C

 

From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Tuesday, 17 September 2019 at 19:33
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] key_schema in TOSCA 1.3?

 

Thanks everybody for the discussion and quick decision!

 

As an addendum, I'll just point out there is a workaround for cases where you need to send a map with arbitrary keys to an external system. Just use a list of entries:

 

data_types:

  MyEntry:

    Key: MyKeyType

    Value: MyValueType

 

node_types:

  MyNode:

    properties:

      my_fake_map:

        type: list

        entry_schema: MyEntry

 

The one caveat is that TOSCA would not be able to verify the uniqueness of keys, but at least there is a functional solution.

 

Is it worth pointing this out in the spec to preempt questions about the key_schema limitation?

 

 

On Mon, Sep 16, 2019 at 4:15 PM Chris Lauwers <lauwers@ubicity.com> wrote:

As a compromise, perhaps we can restrict key_schema to only allow scalar types (or types that derive from scalar types).

 

Chris

 

From: Tal Liron [mailto:tliron@redhat.com]
Sent: Monday, September 16, 2019 10:09 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] key_schema in TOSCA 1.3?

 

I would like to ask the group to reconsider the new "key_schema" feature.

 

While it's true that complex keys are supported in YAML, hashtables with complex keys are not widely supported across programming languages, data formats (JSON), databases (relational, graph), memory caches, etc.

 

In working to implement this feature in Puccini I am hitting many problems that would require adding workarounds with considerable complexity, in particular in its interfaces with the orchestration systems it supports.

 

My guess is that it was added to provide some grammatical completeness, but I would like to re-discuss its practicality and necessity. Can we add this to the meeting agenda?

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]