Hi,

Please find the traceback for the crash on the very first insert into AnnaDB: https://gist.github.com/taurus-forever/56492ae09c13b94e1a4788241d432a34

The command was copied from the documentation: https://annadb.dev/documentation/insert/#example

Hi there,

I wonder how I would get a single entry by using a UUID in Python. The code below gives me this error: "Get query can contain only links"

from annadb import Connection
from uuid import UUID

db = Connection.from_connection_string("annadb://localhost:10001")


def get(container: str, id: UUID) -> None:
    container = db[container]
    response = container.get_one(id).run()
    print(response)
    

get("category", "bd6b60a1-02c3-401f-954b-f136b7f62b25")

$ annadb --uri annadb://playground.annadb.dev:10001
Traceback (most recent call last):
  File "c:\python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Python39\Scripts\annadb.exe\__main__.py", line 4, in <module>
  File "c:\python39\lib\site-packages\annadb\__init__.py", line 18, in <module>
    from annadb.connection import Connection
  File "c:\python39\lib\site-packages\annadb\connection.py", line 6, in <module>
    from annadb.dump import to_str
  File "c:\python39\lib\site-packages\annadb\dump.py", line 1, in <module>
    from types import NoneType
ImportError: cannot import name 'NoneType' from 'types' (c:\python39\lib\types.py)

https://github.com/roman-right/AnnaDB/blob/17e85f13532f864911586d9cf1b1e734d762de4b/drivers/python/annadb/dump.py#L1

I am not much of a python developer, but I think this StackOverflow answer might also help:

https://stackoverflow.com/a/15844751/1707323

There is no longer a NoneType reference in the types modules. You should just check for identity with None directly, i.e. obj is None. An alternative way, if you really need the NoneType, would be to get it using:

NoneType = type(None)

This is actually the exact same way types.NoneType was previously defined, before it was removed on November 28th, 2007.

I am thinking of a use case for this database, and one point is building a layer of abstration on top of this underlying simplicity. One of my goals is to reduce the data footprint by storing data with singularity. In order to do that though, I would need to be able to do a single operation where I have a value and I want to either insert it as a new item and return the item id, or if it already exists, I want to return the item id of the existing item and not insert it.

Here is what that might look like in TySON:

collection|strings|:q[
  find[
    eq{root:s|foo|}
  ],
  if[
    lt{count:n|1|},
    insert[s|foo|]
  ]
]

There are times, when the collection context would be beneficial. Knowing not just the data that is linked to, but that it is linked data from another collection. How does one know they are updating data from a different collection. This is assuming that when inserting data with links, the linked data nodes are not copied but are just "linked"

I propose some kind of structure where you keep the context of the linked collection in the tree.

Let me know if you need some examples of my thoughts and reasonings here.

I think the error was trying to point to the test|... part of the string, but it did not point there successfully probably due to the query being parsed out and line separated. I expect this to point to the correct part of the string which can be seen if I follow the arrow up to the original query.

Furthermore, all I was missing was the ending pipe | which I have done quite often while working with this syntax. That specific error I believe could be parsed out better and almost know that a pipe is missing. This might even be able to use a regex noting that the pipes do not exist evenly

What you did:

collection|person|:insert[
  m{s|name|:s|Foo|},
  m{s|name|:s|Bar|}
]

Let's say these were generated with the ids:

Foo: f35dbd14-65e5-482f-a6e3-82c18b1aaaa7 Bar: b70fd0a3-a780-4b0c-a095-c832b4261809

I then inversely connected them together so that I could see that they were mutual friends

collection|person|:q[get[person|f35dbd14-65e5-482f-a6e3-82c18b1aaaa7|],update[set{value|friends|:v[person|b70fd0a3-a780-4b0c-a095-c832b4261809|]}]]
collection|person|:q[get[person|b70fd0a3-a780-4b0c-a095-c832b4261809|],update[set{value|friends|:v[person|f35dbd14-65e5-482f-a6e3-82c18b1aaaa7|]}]]

The updates were successfully applied, but then I tried to query them:

collection|person|:get[
  person|f35dbd14-65e5-482f-a6e3-82c18b1aaaa7|,
  person|b70fd0a3-a780-4b0c-a095-c832b4261809|
]

What Happened

But this created an error: Fetch recursion error

If I didn't know what to update to remove the recursion, I would have no way to research it. I can no longer query these nodes, and I would might as well delete them and start over.

Ideas:

I think loops should be allowable. I was thinking about this, and think the better way to handle it would be depth limiting. And why I think loops would be a good thing is when you get into graphs (looking at your roadmap) you will want to be able to traverse a graph up and down.

What you wanted to do

Nested inserts of nodes. Insert items into a collection and in a nested manner, insert items into the same or different collections.

What you did instead

I could insert vectors and maps, but these vectors and maps would all be part of the same item in the parent collection and could not be queried from other collections.

collection|person|:q[
  insert[
    person|foo|:m{
      s|name|:s|Foo|
    }
  ],
  insert[
    m{
      s|name|:s|Bar|,
      s|friends|:v[
        person|foo|
      ]
    }
  ]
]

The work around to this is to do back to back inserts into collections and handle the linking in subsequent queries insert operations.

Ideas on what this might look like

What if inserts could be cascaded. Right now it seems nothing can come in the pipe after an insert. But what if you could do something like this for starters:

collection|person|:q[
  insert[
    person|foo|:m{
      s|name|:s|Foo|
    }
  ],
  insert[
    m{
      s|name|:s|Bar|,
      s|friends|:v[
        person|foo|
      ]
    }
  ]
]

The person|foo| is a temporary id that is not persisted. It is used for cross reference in the same transaction. And then if you could do that then you could also probably do something like:

collection|person|:insert[
  m{
    s|name|:s|Bar|,
    s|friends|:v[
      person|:m{
        s|name|:s|Foo|
      }
    ]
  }
]

And combine these two to be able to create inverse relationships (see issue __):

collection|person|:insert[
  person|bar|:m{
    s|name|:s|Foo|,
    s|friends|:v[
      person|foo|:m{
        s|name|:s|Foo|,
        s|friends|:v[
          person|bar|
        ]
      }
    ]
  }
]

The person|foo| in this query is not being referenced anywhere else so in theory, this could be person| and work the same way.

And this would also allow to insert more than one collection at a time. This is where it might get complicated not knowing how the resolvers for insert work.

collection|post|:insert[
  post|p1|:m{
    s|title|:s|Check Out AnnaDB!|,
    s|comments|:v[
      comment|c1|:m{
        s|text|:s|This is pretty awesome!|,
        s|onPost|:post|p1|
        replies:v[
          comment|:m{
            s|text|:s|For sure!|,
            s|replyTo|:comment|c1|
          }
        ]
      }
    ]
  }
]