Added NOW already and now debuging some stuff regarding filter and
parsing file of one struct when it should be another
Also moved query test into a seperated test file.
And some fix and changed in docs
This dosnt work yet but I implemented the reparsing of the files to
return relationship.
So GRAB User [name, friends] should return all infos of all friends and
not just the UUID of those friends like before
Now SchemaEngine have an arena at the root of the file. So UUIDFileIndex
can be as big as we want. The idea is nice, maybe I will use it for the
FileEngine too.
Started to use fixed buffer at the root of each file. I like that
because that mean I can estimate the amount of memory that the app use.
The only thing that still use an non fixed allocator is the
UUIDFileIndex, but I dont like it. I think it should also use a fixed
lenght buffer. But then how can I be sure it is enough ? :/
I mean I get it, I need an allocator here. But if this is the only place
I use one, this a shame
Before I was checking after the filter.evaluate is true. So I can end up
with the limit reach, but the thread will continue parsing until it find
one that is true, add it and then check if the limit is reach.
Which mean I endup with more than what I want and the thread could stop
before, making things faster.
Created a new folder to clean a bit the repo, put the file and schema
engine inside. As those and Parser depend on the types.zig, I also add
this folder inside the new engines folder
Created a new Parser unique for the FileEngine to read each line.
It is slower as I need to parser character by character because their is
no fixed len for the data in files. Before I was just reading until the
end of the file.
Im gonna need to find some tricks to improve the parsing of data. I am
thinking using the stream directly instead of doing streamUntilDelimiter
