Indexes on vectors return surprising results
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by running the two reproduction snippets and tracing the d/datoms :avet lookup for the indexed :path attribute. Compare vector, list, and sequence inputs with and without the additional :children datom; done means the lookup behaves consistently and only matches the intended indexed values.
Written by the indexing model from the issue text.
Description
I'm seeing some odd behavior with indexed vectors. I thought this might have been introduced in 1.6.4, but it was also happening in 1.6.3. Given
(let [db (-> (d/empty-db {:path {:db/index true}})
(d/db-with [{:path [1 2]}
{:path [1 2 3]}]))]
(for [v [;; variations on 1, 2
[1 2]
(list 1 2)
(butlast [1 2 3])
;; variations on 1, 2, 3
[1 2 3]
(list 1 2 3)
(butlast [1 2 3 4])]]
[v
(->> (d/datoms db :avet :path v)
(mapv :e))]))
I'd expect this to only find entity ids for the first and fourth values of v, i.e. for the vectors, not the lists or sequences. However, this is what is returned.
;; => ([[1 2] [1]]
;; [(1 2) [1]]
;; [(1 2) []]
;; [[1 2 3] [2]]
;; [(1 2 3) []]
;; [(1 2 3) [2]])
It's particularly odd that first list, (list 1 2) returns an entity id but (list 1 2 3) doesn't. And contrarily that the first sequence (butlast [1 2 3]) doesn't return an entity id but (butlast [1 2 3 4]) does.
As I was playing with this I also ran across another odd variation. The presence of other datoms seems to affect the result.
(let [db (-> (d/empty-db {:path {:db/index true}
;; this attribute is new
:children {:db/valueType :db.type/ref
:db/cardinality :db.cardinality/many}})
(d/db-with [{:db/id "a"
:path [1 2]}
{:db/id "b"
:path [1 2 3]}
;; this datom is new
[:db/add "a" :children "b"]]))]
(for [v [;; variations on 1, 2
[1 2]
(list 1 2)
(butlast [1 2 3])
;; variations on 1, 2, 3
[1 2 3]
(list 1 2 3)
(butlast [1 2 3 4])]]
[v
(->> (d/datoms db :avet :path v)
(mapv :e))]))
;; => ([[1 2] [1]]
;; [(1 2) [1]]
;; this result has changed
;; [(1 2) [1 2]]
;; [[1 2 3] [2]]
;; [(1 2 3) []]
;; [(1 2 3) [2]])
Here the result is almost the same, except that whereas before when v was (list 1 2), d/datoms returned nothing. Now, with the other datom, it returns both entity ids. Very odd!
The easiest fix is, on the calling side, to be careful to pass vectors not sequences. That's what we'll do in our project, but I wanted to report the issue anyway.
- Dominant language
- Clojure
- Stars
- 5.8k
- Forks
- 318
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tonsky/datascript
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
tonsky/datascript#498 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
tonsky/datascript#489 ·
-
Stack overflow when transacting :db.type/tupleAttrs with a :db.type/ref attr through :db.fn/call Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
tonsky/datascript#483 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
tonsky/datascript#441 · 1 comment · 3 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
tonsky/datascript#434 · 2 comments ·
All issues in tonsky/datascript
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
.Team/Metabot Priority:P3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
needs triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
scalar-labs/scalar-jepsen#222 · 1 comment ·