Update Docs
This commit is contained in:
parent
ef84200b34
commit
f1c2bea5c1
@ -100,6 +100,11 @@ The main action is `GRAB`, this will parse files and return data.
|
||||
GRAB User {name = 'Bob' AND (age > 30 OR age < 10)}
|
||||
```
|
||||
|
||||
Here a preview to how to use relationship.
|
||||
```js
|
||||
GRAB User {best_friend = {name = 'Bob'}}
|
||||
```
|
||||
|
||||
GRAB queries return a list of JSON objects with the data inside, e.g:
|
||||
```
|
||||
[{id:"1e170a80-84c9-429a-be25-ab4657894653", name: "Gwendolyn Ray", age: 70, email: "austin92@example.org", scores: [ 77 ], friends: [], }, ]
|
||||
@ -204,7 +209,6 @@ TODO: Create a tech doc of what is happening inside.
|
||||
- [ ] Relationships
|
||||
- [X] Custom data file
|
||||
- [X] Date
|
||||
- [ ] Linked query
|
||||
- [X] Logs
|
||||
- [X] Query multi threading
|
||||
|
||||
@ -213,6 +217,7 @@ TODO: Create a tech doc of what is happening inside.
|
||||
- [ ] Dump/Bump data
|
||||
- [ ] Recovery
|
||||
- [ ] Better CLI
|
||||
- [ ] Linked query
|
||||
|
||||
### Beta
|
||||
#### v0.4 - Usability
|
||||
|
@ -4,7 +4,7 @@
|
||||
Relationships
|
||||
- [X] Update the schema Parser and Tokenizer
|
||||
- [X] Include the name of the link struct with the schema_struct
|
||||
- [ ] New ConditionValue that is an array of UUID
|
||||
- [X] New ConditionValue that is an array of UUID
|
||||
- [ ] When relationship found in filter, check if the type is right and exist
|
||||
- [ ] When parseFilter, get list of UUID as value for relationship
|
||||
- [ ] Add new operation in Filter evalue: IN and !IN
|
||||
@ -22,16 +22,39 @@ Optimizations
|
||||
|
||||
ADD User (name='Bob', age = 44, best_friend = {id=0000-0000}) => new_user => UPDATE User {id = 0000-0000} TO (best_friend = new_user)
|
||||
|
||||
GRAB User [friends] {best_friends IN {name = 'Bob'}}
|
||||
|
||||
### Question. How de fuck I am parsing files to get relationships ?
|
||||
I dont want to parse them more than 3, best 2, perfect 1
|
||||
|
||||
The issue is that, I could do optimization here but I dont have enough yet. I need to start doing something that work then I will see.
|
||||
So I parse:
|
||||
- All files that
|
||||
|
||||
Now this is where the Radix tree come into place. Because if I get to find one UUID in 50000 files, and I parse all of them, this is meh.
|
||||
So I need a Radix tree to be able to find all file to parse.
|
||||
|
||||
1. Get the list of UUID that need to be parse.
|
||||
For example if I do "GRAB User [mom] {name = 'Bob'}". I parse one time the file to get all UUID of User that represent mom; the parse that is already done and need to be done. So if I found 3 Bob's mom UUID
|
||||
2. Then I create a map of Bob's UUID as keys and a Str as value. The Str is the JSON string of the mom. For that I need to parse the file again and write using additional_data
|
||||
|
||||
### Radix tree
|
||||
|
||||
Ok so new problem. Given a list of UUID, I need a way to find all file index to parse.
|
||||
And even better if I can get the number of UUID per files, so I can stop parsing them early.
|
||||
|
||||
Happy to annonce the v0.2 of my database. New feature include:
|
||||
- Relationship
|
||||
- Huge performance increase with multi threading
|
||||
- Date, time and datetime type
|
||||
- Linked query
|
||||
- Compressed binary files
|
||||
- Logs
|
||||
|
||||
All core features of the query language is working, v0.3 will focus on adding things around ot, including:
|
||||
All core features of the query language, exept linked queries, is working, v0.3 will focus on adding things around it, including:
|
||||
- Schema migration
|
||||
- Dump/Bump data
|
||||
- Recovery
|
||||
- Better CLI
|
||||
|
||||
Query optimization for later:
|
||||
- If a filter use id to find something, to stop after find it, as I know there is no other struct with the same id
|
||||
|
11
docs/ZiQL.md
11
docs/ZiQL.md
@ -107,7 +107,7 @@ This also works by using other filters. Here I get `User` entities that have a b
|
||||
GRAB User { bestfriend IN { name = 'Adrien' } }
|
||||
```
|
||||
|
||||
When using an array with `IN`, it will return all User entities that have at least one friend named Adrien:
|
||||
When using an array with `IN`, it will return all User entities that have AT LEAST one friend named Adrien:
|
||||
```js
|
||||
GRAB User { friends IN { name = 'Adrien' } }
|
||||
```
|
||||
@ -189,13 +189,14 @@ ADD User (name = 'Bob', age = 30, email = 'bob@email.com', scores = [1 100 44 82
|
||||
|
||||
You need to specify all members when adding an entity (default values are coming soon).
|
||||
|
||||
#### Not yet implemented
|
||||
|
||||
The `ADD` query will return a list of added IDs, e.g.:
|
||||
```
|
||||
["1e170a80-84c9-429a-be25-ab4657894653", "1e170a80-84c9-429a-be25-ab4657894654", ]
|
||||
```
|
||||
|
||||
#### Not yet implemented
|
||||
|
||||
And you can also add them in batch
|
||||
```js
|
||||
ADD User (name = 'Bob', age = 30, email = 'bob@email.com', scores = [1 100 44 82]) (name = 'Bob2', age = 33, email = 'bob2@email.com', scores = [])
|
||||
@ -213,8 +214,6 @@ Similar to `GRAB` but deletes all entities found using the filter and returns a
|
||||
DELETE User {name = 'Bob'}
|
||||
```
|
||||
|
||||
#### Not yet implemented
|
||||
|
||||
The `DELETE` query will return a list of deleted IDs, e.g.:
|
||||
```
|
||||
["1e170a80-84c9-429a-be25-ab4657894653", "1e170a80-84c9-429a-be25-ab4657894654", ]
|
||||
@ -230,13 +229,13 @@ UPDATE User [5] {name='adrien'} TO (name = 'Adrien')
|
||||
|
||||
Note that, compared to `ADD`, you don't need to specify all members between `()`. Only the ones specified will be updated.
|
||||
|
||||
#### Not yet implemented
|
||||
|
||||
The `UPDATE` query will return a list of updated IDs, e.g.:
|
||||
```
|
||||
["1e170a80-84c9-429a-be25-ab4657894653", "1e170a80-84c9-429a-be25-ab4657894654", ]
|
||||
```
|
||||
|
||||
#### Not yet implemented
|
||||
|
||||
You can use operations on values themselves when updating:
|
||||
```js
|
||||
UPDATE User {name = 'Bob'} TO (age += 1)
|
||||
|
Loading…
x
Reference in New Issue
Block a user