Getting the whole guild object, editing just that channel, updating whole guild is inefficient tbh
with hasmaps no problem
maybe you should google how that works
yea im not aware how that works
ill check
But you’re telling like guild.channels would be a hashmap?
or store channels as hashmap separately and bind to guild when needed?
Not sure how scalable or fast the latest postgres JSON query module would be but it might be worth a look
Hey @inclusive-numbat, sorry for the ping but I wanted to see if this RedisJSON, RediSearch support is there yet cuz someone told me like it is supporting now so wanted to verify, is dragonflydb doing that yet?
Hi @praiseworthy-antelop - we do support JSON but no json search yet
Alright, and how’s the plan for that going? Still gonna do?
Yes, at some point, but not in Q1 
aight ty for your time
We are actually working on a project that can extend the functionality of DragonFly to allow clients to work with Graphs, Documents, and Search, like RedisGraph, RedisJSON and RediSearch.
It is called UKV, it is designed as an ecosystem around Key-Value Stores. A middleware, if you will. It supports a few Key-Value Stores out of the box, as well numerous language bindings. Our language bindings for Python, for example, mimic Pandas and NetworkX.
So if DragonFly was to be implemented as one of the engines, millions of Python user would get the ability to transparently put their documents and graphs into a remote distributed in-memory DBMS by changing a single import pandas or import networkx line. How cool is that?
I will leave the link to our GitHub here: https://github.com/unum-cloud/ukv
As well as our Discord: https://discord.gg/S6bYJsfFg9
Feel free to ask anything!
Cool project but I have not seen anything related to inmemory stores there.
The UMem part is entirely in-memory. It is backed by this tiny repo at the moment, but we will ad more concurrent containers in the future. https://github.com/unum-cloud/ucset
I meant remote inmemory stores via tcp
We originally designed UKV as a primary interface for our persistent embedded Key-Value Store. At our speeds we had no other choice, but to design it 1. There are presently 4 backends available, but none of them is horizontally scalable. In case you implement one for DragonFly, it will be the first of its kind.
From looking at your numbers, I thought something like this can benefit DragonFly as well 
In case someone wants to implement a DragonFlyDB connector, here is a GitHub issue. https://github.com/unum-cloud/ukv/issues/239