Fork me on GitHub
#datomic
<
2020-12-09
>
mruzekw00:12:34

Hi all, I'm looking into Datomic for a new project of mine that might have live-collaborative editing. I noticed that Datomic Cloud doesn't allow use of the tx-report-queue to broadcast updates. Are there any alternative solutions for Datomic Cloud for realtime updates? Thanks!

Saurabh Sharan01:12:50

I think you should be able to use tx-range, but you’ll have to manage the cursor into the transaction log yourself https://docs.datomic.com/cloud/time/log.html

Sam DeSota19:12:47

Hey, I'm running into a really strange issue with datomic boot datoms. A member on my team accidentally transacted to an entity with :db/id 3 , but that entity refers to a "boot" datom. I think datomic should have rejected the transaction, but unfortuntely it allowed it:

{:t 1095565,
  :data
  [#datom[13194140628877 50 #inst "2020-12-09T18:09:14.299-00:00" 13194140628877 true]
   #datom[3 95 :order.status/fulfillManual 13194140628877 true]]}
Now, It's impossible to remove this datom. When trying to retract, I get:
:db.error/datom-cannot-be-altered Boot datoms cannot be altered: ...
We have many queries that depend on this attribute having valid data, that are now broken. Is there anyway to retract this mistake?

jaret19:12:43

Hi @USQ5P4FT4 Is this dev-local, on-prem, cloud db? Also how important is this database?

jaret19:12:37

You can transact your own facts about system entities (emphasis entities, not datoms). You cannot retract such facts. That being said, I need to create a reproduction of this issue and I imagine that a query workaround is to have queries ignore entities in the system partition (partition 0). Are you seeing any errors? The entity that was altered pointed to:

jaret19:12:40

#:db{:id 3,
     :ident :db.part/tx,
     :doc "Partition used to store data about transactions. Transaction data always includes a :db/txInstant which is the transaction's timestamp, and can be extended to store other information at transaction granularity."}

jaret19:12:46

I guess I know you are saying you have queries that depend on that attribute having valid data, but I want to understand if you are seeing errors outside of query data validation.

jaret19:12:46

If you get a chance shoot an email to <mailto:[email protected]|[email protected]> so I can track this issue with a ticket and we can share relevant details.

Sam DeSota19:12:43

Hi Jaret. This is with on-prem. It's a mission critical database. Needed to fix this, so what I did is I created a new entity, copied the old entity data to the new entity, then renamed the entity to the old entity name. Of course this will mean historical queries will be weird, but had to be fixed. Will send an email to support with details to create a ticket, thank you!

Chicão19:12:40

Hi, I'm trying to select user by name and email, but if email and name are empty return all users This is my query but works only when I have email and username

(->> (d/q '{:find  [[(pull ?user [:user/id
                                    :user/name
                                    :user/email])

                       ...]]
              :in    [$ ?name ?email]
              :where [[?user :user/consumer]
                      [?user :user/email ?email]
                      [?user :user/name ?name]
                      [(util/includes? ?name ?email)]]}
            db (or username "") (or email "")))
May someone can help me?

Lennart Buit20:12:48

I’m not sure I’m understanding what you are saying, but you can generate query maps programatically, its just a map, after all — say if ?name is not provided, not generate the [?user :user/name ?name] clause

Chicão20:12:42

If the name and email was not provide return all entity