Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow parts of key names called meta and value #10

Open
markus2330 opened this issue Aug 2, 2022 · 2 comments
Open

allow parts of key names called meta and value #10

markus2330 opened this issue Aug 2, 2022 · 2 comments

Comments

@markus2330
Copy link
Collaborator

Currently, we simply use "meta" and "value" with special meaning. This makes it impossible to actually use parts of key names with "meta" and "value", which is not so unlikely.

In doc/decisions/semantics_name.md @kodebach proposed to use ®elektra in such cases.

In another case (fuse binding) we used @elektra. So probably we should first review doc/decisions/semantics_name.md if we stay with the decision. (And create an issue that the fuse binding needs to be fixed). Alternatively, we could use @elektra/meta etc. and revise the decision.

@kodebach
Copy link
Member

kodebach commented Aug 2, 2022

Currently, we simply use "meta" and "value" with special meaning. This makes it impossible to actually use parts of key names with "meta" and "value", which is not so unlikely.

What is this referring to? Sorry, I missed that this is in the ansible repo....

Yes, that is a problem, but I'm not sure "®elektra/meta and ®elektra/value" is the solution. It would be really awkward to use.

First of all, I think this should work:

    - name: set example vegetables
      elektra:
        mountpoint: user:/tests/ansible/vegetables
        keys:
          tomato: ketchup
          potato: fries

Secondly, do we actually translate YAML arrays into Elektra array, i.e. what happens with this:

    - name: set example vegetables
      elektra:
        mountpoint: user:/tests/ansible/vegetables
        keys:
          tomato:
            - ketchup
            - sauce

Because one easy way to fix this would be:

    - name: set example vegetables
      elektra:
        mountpoint: user:/tests/ansible/vegetables
        keys:
          # works as expected, sets values for tomato and potato
          tomato: ketchup
          potato: fries
          # if you need meta and value or values on non-leaf nodes
          fruit:
            apple:
              - value: pie
              - meta:
                  type: string
                  default: juice
            berries:
              - value: bush
              - keys:
                  raspberry: pi
                  blueberry: muffin

We'd need to check that all the objects in the array only contain one key, which must be value, meta or keys and that nothing is repeated, but it would work.

If we do (or want to) translate YAML arrays it could still work, with a bit of fudging:

    - name: set example vegetables
      elektra:
        mountpoint: user:/tests/ansible/vegetables
        keys:
          # works as expected, sets values for tomato and potato
          tomato: ketchup
          potato: fries
          animals:
            - array:
                - species: cow # sets /animals/#0/species = cow
                  name: Bessie # sets /animals/#0/name = Bessie
                - species: dog
                - species: sheep
          # if you need meta and value or values on non-leaf nodes
          fruit:
            apple:
              - value: pie
              - meta:
                  type: string
                  default: juice
            berries:
              - value: bush
              - keys:
                  raspberry: pi
                  blueberry: muffin

@markus2330 markus2330 changed the title ®elektra/meta and ®elektra/value allow parts of key names called meta and value Aug 3, 2022
@markus2330
Copy link
Collaborator Author

I like the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants