Hey @esp1, if you change the schema around a little bit you could use tuples to accomplish this. Composite tuples in particular.
Thanks for replying @lanejo01! I tried this but I'm unclear on what tuple attrs to use to make this work. I tried:
{:db/ident :node.config/parent+type
:db/valueType :db.type/tuple
:db/tupleAttrs [:node/_configs :node.config/type]
:db/cardinality :db.cardinality/one
:db/unique :db.unique/identity}
but when I try to transact this I get :db.error/invalid-tuple-attrs
. Could you give me a little more detail on what schema changes you had in mind to accomplish this?:node/_configs
should probably just be :node/configs
(no underscore).
Hi @oscarlinusericsson - I tried that as well, but it also fails with the same :db.error/invalid-tuple-attrs
error (maybe because :node/configs
is cardinality many?). I used the inverse :node/_configs
attribute originally because I am assuming that the tuple attributes would need to be on the same entity, and :node/configs
is on the parent entity and :node.config/type
is on the child component. This is why I'm confused as to how to make this work.. 😅
@esp1 it sounds like the combination of :node/id
and :node.config/type
might represent an entity you haven't named yet. Composite tuples can't use backrefs, if you must use a tuple, you will need to flatten out the relationship.
There may be other approaches to modeling your domain though, so think about it hard.
Hm. I could flatten the 1-many relation between node and config by inverting it and having the config entities point back to the node (having a :node.config/parent-node
attribute on the configs). This will let me create a composite tuple with attrs [:node.config/parent-node :node.config/type]
, but then I can no longer use :db/isComponent
to indicate that the configs are components of the node, so retracting a node will no longer automatically retract its configs. I suppose I could use a custom transaction function to handle the retractions tho.
Is it possible to pass rules to a https://docs.datomic.com/cloud/query/query-data-reference.html#q in datomic cloud? Example in thread Edit: I think I figured it out. I also posted my conclusions in the thread.
When I try it I get an exception that says
Unable to resolve symbol: % in this context
A really simplified case looks something like this
(d/q '[:find ?t ?thing-count
:in $ %
:where
[?t :thing/id ?id]
[(q '[:find (count ?t)
:in $ %
:where
(active-thing ?t)]
$ %)
[[?thing-count]]]
[?t :thing/color "blue"]]
db rules)
I've tried shuffling around just passing in $
, not using :in
in the nested query, adding quotes in different places, using the map form of a query for the nested q
. Nothing has worked so far.As soon as I got this posted I figured it out. I can just bind the rules to a symbol like ?rules
and pass it in that way.
For the curious, it looked something like
(d/q '[:find ?t ?thing-count
:in $ ?rules
:where
[?t :thing/id ?id]
[(q '[:find (count ?t)
:in $ %
:where
(active-thing ?t)]
$ ?rules)
[[?thing-count]]]
[?t :thing/color "blue"]]
db rules)
I can't use the rules in the top level of the query when it's bound to ?rules
. But I can pass in the same set of rules twice, and bind one at the top level %
and the other to ?rules
. What a trip!
I am thinking of using Google Firebase to power authentication and store user data for Android, iOS. For financial data (deposits, wallet balance) I am going to use Datomic on AWS. I would like to use Firebase for rapid realtime response but datomic as an "ultimate authority of truth". ex) Firebase shows deposits instantly. but this is not reflected in Datomic yet. Is this a viable strategy? syncing firebase and datomic somehow? or Should I be using Datomic always? Read data, write data to datomic without relying on Firebase? It might be slow at some point if there are lot of writes (I read Datomic isn't built for large volume of writes) and I'm afraid that it might impact the user experience on mobile app side. I am trying to justify using Datomic to my team. Since we are dealing with real money, we need an immutable log, and ability to look at snapshots of the past, meet regulations but overall concerned about the impact of network performance that might trickle to the end user (as a result of calling datomic on AWS api gateway/lambda from google firebase cloud functions)