From b0071beb0a9cfbe025e0f973f31a2eedc4fa374d Mon Sep 17 00:00:00 2001
From: Chung Quan Tin <tin@snowflake.so>
Date: Sun, 6 Nov 2022 10:18:44 +0700
Subject: [PATCH] Add workflow for generating changelog

---
 .github/workflows/changelog.yml | 13 +++++++++++++
 .gitignore                      |  1 +
 docs/WIKI.md => WIKI.md         | 23 +++++++++++++++++++++++
 db/src/storage/mod.rs           | 26 +++++++++++++++-----------
 4 files changed, 52 insertions(+), 11 deletions(-)
 create mode 100644 .github/workflows/changelog.yml
 rename docs/WIKI.md => WIKI.md (57%)

diff --git a/.github/workflows/changelog.yml b/.github/workflows/changelog.yml
new file mode 100644
index 0000000..eaacab2
--- /dev/null
+++ b/.github/workflows/changelog.yml
@@ -0,0 +1,13 @@
+name: Changelog
+on:
+  release:
+    types:
+      - created
+jobs:
+  changelog:
+    runs-on: ubuntu-20.04
+    steps:
+      - name: "✏️ Generate release changelog"
+        uses: heinrichreimer/github-changelog-generator-action@v2.3
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.gitignore b/.gitignore
index 79fda82..3905033 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 **/target
 **/.temp
 .DS_Store
+.env
\ No newline at end of file
diff --git a/docs/WIKI.md b/WIKI.md
similarity index 57%
rename from docs/WIKI.md
rename to WIKI.md
index 152d374..6b161cb 100644
--- a/docs/WIKI.md
+++ b/WIKI.md
@@ -39,3 +39,26 @@ To construct a successful query language is not easy. It requires a lot of deep
 The parsed tokens will be handled by a query logical planner which transform those tokens to relational algebra and execute based on the instructions.
 
 ### Brain storming database design & architecture
+
+After a few days of researching and reading **O'Reilly Graph Database** book (it was a very good book for graph database introduction actually), I decided to stumble into experimenting.
+
+It was quite hard to identify the uniqueness of Solomon DB. The main reason is there are too many databases already. From production-ready databases like **Cassandra, PostgreSQL** or a common graph database like **Neo4j** and **JanusGraph**. Even though my desire for being able to design an outstanding architecture is quite high, I position my current skills not capable of that. Hence, instead of trying to over complicate everything, I think starting small steps and climb up stair by stair might be a better strategy.
+
+I got inspired by the design of SurrealDB which does not build its own underlying layer but trying to maximize the power of multiple databases. And I think it is a good design to try. So the main architecture of SolomonDB will be:
+
+#### Underlying storage
+
+There are two NoSQL databases that fascinate me due to its design and scalability.
+
+-   **RocksDB:** The popular key-value database designed and maintained by team at Facebook. It is used widely by several big databases as an underlying storage. The use of RocksDB will be elaborated more in a later chapter.
+-   **Cassandra:** For anyone who works with big data, is quite familiar with this wide-column database. Cassandra is a big guy in the field with its distributed architecture and several other features for streaming and configuring node instances.
+
+#### Property graph data structure & algorithms
+
+The concepts of property graph data structure is used commonly in production system which is **read contention** and graph driven. A quite well-known examples of property graph are social network.
+
+Solomon DB will use property graph data structure to present the graph data in the system. The main problems of this data structure is applying algorithms designed for single relational graph will be a bit complicated.
+
+#### Modelling graph data
+
+Facebook's TAO graph database has a very well-explained white paper that demonstrates the approach to design Property Graph. Core components of Solomon graph model will be **Node, Relationship, Property and Label**.
diff --git a/db/src/storage/mod.rs b/db/src/storage/mod.rs
index 464ccdb..c401f36 100644
--- a/db/src/storage/mod.rs
+++ b/db/src/storage/mod.rs
@@ -5,21 +5,25 @@ pub use kvs::*;
 macro_rules! register_adapter {
  ($name:ident, $($x:ident),*) => {
    use $crate::model::adapter::DatastoreAdapter;
+   /// # Datastore Manager
+   /// A generated enumeration Datastore Manager to dynamically register
+   /// and return the datastore adapter without being constrained by the
+   /// type system.
+   #[allow(dead_code)]
    pub enum DatastoreManager {
-       $(
-           $x,
-       )*
+    $($x)*
    }
 
+   #[allow(dead_code)]
    impl DatastoreManager {
-       pub fn $name(&self) -> $( $x)*
-       {
-           match self {
-               $(
-                  DatastoreManager::$x => $x::default(),
-               )*
-           }
-       }
+    pub fn $name(&self) -> $($x)*
+    {
+        match self {
+            $(
+                DatastoreManager::$x => $x::$name(),
+            )*
+        }
+    }
    }
   };
 }