# Upsert behavior with composite tuple key

**URL:** https://forum.datomic.com/t/upsert-behavior-with-composite-tuple-key/1075
**Category:** Datomic Cloud
**Created:** [July 11, 2019, 4:51pm UTC](https://forum.datomic.com/t/upsert-behavior-with-composite-tuple-key/1075 "2019-07-11T16:51:59Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/jacob/32/302_2.png) [@jacob](https://forum.datomic.com/u/jacob)
#### Post date: [July 12, 2019, 6:30pm UTC](https://forum.datomic.com/t/upsert-behavior-with-composite-tuple-key/1075/2 "2019-07-12T18:30:35Z")

</div>

Update: upsert is completely broken when the key tuple includes a false boolean value. Example from my application:

```clojure
(d/transact sys/conn
            {:tx-data [{:rec.oc/track 9895604649984119
                        :rec.oc/user 28666467159376431
                        :rec.oc/hit? false
                        :rec.oc/key [28666467159376431 9895604649984119 false]}]})
Unique conflict: :rec.oc/key, value: [28666467159376431 9895604649984119 false] already held by: 18159534044352573 asserted for: 4925812092440654

```

I’m assuming this is related to [this](https://forum.datomic.com/t/bug-in-db-ensures-boolean-attr-handling/1073/2). Notes:

- False values only showed up as nil when using `d/with`, not when doing a real transaction (note `value: [28666467159376431 9895604649984119 false]` in the example above).
- The above example works when using `d/with`, it seems that upsert-for-keys-with-false-values is only completely broken for real transactions (at least when using `d/with` it’s only partially broken 😉 ).

For now I’m thinking I’ll have to just use another attribute in place of booleans, e.g. a keyword attribute with `:true` and `:false` as the values.

---

_[View the full topic](https://forum.datomic.com/t/upsert-behavior-with-composite-tuple-key/1075)._