This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
It looks like one of my previous questions in this room resulted in an improvement to the REST API docs, so I'm posting again here, even though I've already figured it out. The current description of the args
parameter to /api/query
reads thus:
> args - Vector of maps of arguments to query. Each map is a database descriptor that corresponds to a database argument to query. Each descriptor must include a value for :db/alias.
This, however, is misleading. The items in the vector aren't always maps. For references to data sources, maps are needed, but for parameterized queries, they should just be the parameters you want bound.
here's an example POST body, in case that's not abundantly clear: {:q [:find (pull ?layout [*]) :in $ ?layout] :args [{:db/alias "dev/stores"} 277076930200641]}
I am having trouble grokking partitions. Right now, my whole data set is in :db.part/user. The docs say to not do this in production, but I haven’t had much guidance on how to organize partitions.
I have paths that pass through every type of entity, which makes me think multiple partitions will be bad?
things in the same partition are stored next to each other, which optimizes locality of fetching data
I haven’t heard much guidance about using them, but I typically create a new partition for each ‘table'
@arohner: even if they are linked? i.e. entity of type A has a key that points to entities of type B?
entity A will be in the partition you specified when you created it, and entity B will be in the partition you specified, when you created it
right, so if they are in different partitions will searching across that ref be slower then if they are in the same?
partitioning is to keep entities ‘nearby’, so hopefully they’ll come from storage in the same segment
but this is mainly a thing to worry about when your data is much larger than ram, and your queries have to pull a lot of datoms from storage