Figure out how to handle data in keys instead of values

[thomasborgen]

Some formats have interesting data in key names instead of in values.

For example JSONSchema.

{
  "$id": "https://example.com/person.schema.json",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Person",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "description": "The person's first name."
    },
    "lastName": {
      "type": "string",
      "description": "The person's last name."
    },
    "age": {
      "description": "Age in years which must be equal to or greater than zero.",
      "type": "integer",
      "minimum": 0
    }
  }
}

Every child object in "properties" is a fields name. That means that it is interesting data.

We could argue that if its just a key that we would need to know the path to anyways, we don't need to be able to map it. Which is fair. But the properties object could have any amount of children and it definitely feels more like an array than an object.

So what do we do?

Maybe we can support iterating over an objects children?

We also need to consider the reverse. What if we wanted to create this JSONSchema data. How should we go about mapping input data into a key name?

[thomasborgen]

About getting key values:

I think the only case where it would make sense to get the keys are when an object of objects work is basically working like a list like the JSONSchema example above or like this:

{
    "people_by_id": {
        "1": {"name": "John", "age": 21},
        "2": {"name": "Bob", "age": 21},
        "3": {"name": "Roger", "age": 21}
    }
}

If we have a structure like this, then more likely than not we want that id number, but we do not want to absolute paths to all objects, we want to iterate over people_by_id.

To get something like that to work we need to figure out a way to represent that in a python dict, because that is what we are using internally, then we would also need to decide on a how it should be looked up in a DataFetcher.

Currently, our iterators makes an object with the given alias available to the DataFetcher. I think we would need to do something similar, but also inject the key name into the aliased object. like this:

{
    "people_item": {
        "__key__": "1",
        "name": "John",
        "age": "21"
    }
}

That way, the only difference internally between an iterated object and an iterated list of object would be that the former have the __key__ key with the original objects key as a value.

[thomasborgen]

About dynamically writing key names

Lets say that we needed to create that JSONSchema from the following csv:

name;type
firstname;string
lastname;string
age;int

There are 2 problems.
First is that when we create a kaiba config we create an object and give it an iterator. What will be produced from that will always be a list. But we don't want a list we want to iterate over some data and produce objects.

Second problem is that we need to be able to dynamically name these objects.

I think that these are two seperate tasks.
To be able to dynamically name an attribute or object we can reuse DataFetcher, but probably give it a spesial name like name_fetcher. This means that we might need to make "name" an object with a default value and a fetched value. (things are getting a bit complicated)

To be able to iterate over some data and produce a list I think we might want to split the kaiba configs "object" into two separate things. One called "list" and one called "object". That way, adding an iterator to an object will always just create an object with named object children. And a list will be create a list of unnamed objects. The "object" config could keep its iterator, but possibly have a spesific datafetcher to name children, which could be something like "path": ["item", "__key__"] when iterating over object with named objects or `"path": ["item", "name"] when iterating normally over another list.

I will start working on some more specific proposals, but these are my initial ideas.

Please let me know how you feel about it @ChameleonTartu I think with this you'd be able to map to and from JsonSchema format in #157