09: performing inserts

In this section you'll look at how you might insert the data Specmonstah has generated into a database. We'll be adding the data to an atom, but you can apply the idea to your own database. The code:
1
(ns reifyhealth.specmonstah-tutorial.09
2
  (:require [reifyhealth.specmonstah.core :as sm]
3
            [clojure.spec.alpha :as s]
4
            [clojure.spec.gen.alpha :as gen]
5
            [reifyhealth.specmonstah.spec-gen :as sg]))
6
​
7
(s/def ::id (s/and pos-int? #(< % 100)))
8
(s/def ::not-empty-string (s/and string? not-empty #(< (count %) 10)))
9
​
10
(s/def ::username ::not-empty-string)
11
(s/def ::user (s/keys :req-un [::id ::username]))
12
​
13
(s/def ::name ::not-empty-string)
14
(s/def ::topic (s/keys :req-un [::id ::name ::owner-id]))
15
​
16
(s/def ::owner-id ::id)
17
(s/def ::topic-id ::id)
18
(s/def ::content ::not-empty-string)
19
(s/def ::post (s/keys :req-un [::id ::owner-id ::topic-id ::content]))
20
​
21
(def schema
22
  {:user  {:prefix :u
23
           :spec   ::user}
24
   :topic {:prefix    :t
25
           :spec      ::topic
26
           :relations {:owner-id [:user :id]}}
27
   :post  {:prefix    :p
28
           :spec      ::post
29
           :relations {:topic-id [:topic :id]}}})
30
​
31
(def database (atom []))
32
​
33
(defn insert
34
  [db {:keys [ent-type visit-val spec-gen]}]
35
  (when-not visit-val
36
    (swap! database conj [ent-type spec-gen])))
37
​
38
(defn ex-01
39
  []
40
  (reset! database [])
41
  (-> (sg/ent-db-spec-gen {:schema schema} {:post [[1]]})
42
      (sm/visit-ents :insert insert))
43
  @database)
44
​
45
(ex-01)
46
;; =>
47
[[:user {:id 7, :username "j29AFqnr"}]
48
 [:topic {:id 2, :name "Qqo04X1Zo", :owner-id 7}]
49
 [:post {:id 70, :owner-id 2, :topic-id 2, :content "al"}]]
Copied!
The specs and schema should be familiar by now. Looking at the ex-01 function, we see that it calls sg/ent-db-spec-gen. As you saw earlier, this creates the ent db and uses clojure.spec to generate a map for each ent, storing the map under the ent's :spec-gen attribute. The resulting ent db is passed to sm/visit-ents with the visit key :insert and visiting function insert.
insert works by:
Checking whether this ent has already been inserted
If not, updating the database atom by conjing a vector of the
ent's type and the value generated by spec-gen.
Let's go through insert line by line:
1
(defn insert
2
  [db {:keys [ent-type visit-val spec-gen]}]
3
  (when-not visit-val
4
    (swap! database conj [ent-type spec-gen])))
Copied!
The second argument to all visiting functions is a map. We're only using the keys :ent-type, :visit-val, and :spec-gen. The full map includes:
All of the ent's attributes (like :spec-gen)
:visit-val, the value from previous visits if there have been any
:visit-key - when the visiting function returns, its value is
added as an ent attr using the key :visit-key
:query-opts - any query opts like {:refs {} :spec-gen {}} for
the ent
:visit-query-opts - any query opts meant for this visiting fn
(when-not visit-val ...), checks whether insert has already visited this ent. (I'll explain why you want to perform this check soon.) If the ent hasn't been visited, the database gets updated by conjing a vector of the ent-type and spec-gen. The database atom ends up with a value like this:
1
[[:user {:id 7, :username "j29AFqnr"}]
2
 [:topic {:id 2, :name "Qqo04X1Zo", :owner-id 7}]
3
 [:post {:id 70, :owner-id 7, :topic-id 2, :content "al"}]]
Copied!
Each ent is inserted in dependency order: :user first, then :topic, then :post.
Now let's revisit (when-not visit-val ...). You want to perform this check because of Specmonstah's progressive construction feature. As we covered in 05: Progressive construction, it's possible to pass an ent-db to successive calls to sm/add-ents. If you added more ents and wanted to insert, you wouldn't want to re-insert previous ents. ex-02 demonstrates this:
1
(defn ex-02
2
  []
3
  (reset! database [])
4
  (-> (sg/ent-db-spec-gen {:schema schema} {:post [[1]]})
5
      (sm/visit-ents :insert insert)
6
      (sg/ent-db-spec-gen {:post [[3]]})
7
      (sm/visit-ents :insert insert))
8
  @database)
9
​
10
(ex-02)
11
;; =>
12
[[:user {:id 6, :username "kUQzVd4S"}]
13
 [:topic {:id 98, :name "I3", :owner-id 6}]
14
 [:post {:id 9, :owner-id 6, :topic-id 98, :content "CEZ"}]
15
 [:post {:id 7, :owner-id 6, :topic-id 98, :content "mU391M"}]
16
 [:post {:id 2, :owner-id 6, :topic-id 98, :content "6ngN"}]
17
 [:post {:id 28, :owner-id 6, :topic-id 98, :content "m4"}]]
Copied!
The :user, :todo-list, and :todo ents from the first call to ent-db-spec-gen are only inserted once, even though they are visited by insert multiple times.
In fact, recall that ent-db-spec-gen internally calls sm/add-ents and then calls the sg/spec-gen visiting function. sg/spec-gen is written with this same principle in mind: it can visit the ent db multiple times, and won't overwrite any existing values. The pattern is common enough that Specmonstah provides the sm/visit-ents-once which you can use instead of sm/visit-ents:
1
(defn insert-once
2
  [db {:keys [ent-type spec-gen]}]
3
  (swap! database conj [ent-type spec-gen])
4
  true)
5
​
6
(defn ex-03
7
  []
8
  (reset! database [])
9
  (-> (sg/ent-db-spec-gen {:schema schema} {:post [[1]]})
10
      (sm/visit-ents-once :insert insert-once)
11
      (sg/ent-db-spec-gen {:post [[3]]})
12
      (sm/visit-ents-once :insert insert-once))
13
  @database)
14
​
15
(ex-03)
16
;; =>
17
[[:user {:id 2, :username "MuGc6"}]
18
 [:topic {:id 87, :name "0Oj9P", :owner-id 2}]
19
 [:post {:id 2, :owner-id 2, :topic-id 87, :content "c6k3Z1HwI"}]
20
 [:post {:id 1, :owner-id 2, :topic-id 87, :content "qEjSKQ"}]
21
 [:post {:id 9, :owner-id 2, :topic-id 87, :content "646nn4bI"}]
22
 [:post {:id 45, :owner-id 2, :topic-id 87, :content "J2vL0Mgi"}]]
Copied!
Instead of having to write a when-not conditional yourself, visit-ents-once checks whether any value exists for the visiting function (even nil or false), and if it does, it doesn't apply the visiting function to that ent.
With this coverage of visit-ents and visit-ents-once, you should be able to handle most use cases. The rest of the guide covers more specific modeling uses cases, like: 
Satisfying a database constraint that there be no two records with the same two foreign keys (e.g. if you're building a forum and don't want a user to like the same post twice)
Modeling an attribute that's a vector of foreign keys
Handling cycles
Using binding to specify that all the refs in an entire hierarchy should refer to a specified ent
Attribute polymorphism (e.g. if a like can refer to either post or a topic)
08: visiting functions
10: uniqueness constraint
Last modified 2yr ago
Copy link