xtdb 2021-08-20 | Slack Archive

richiardiandrea17:08:55

Hi Crux team! I know this might sound like micro-optimization but is there a way to get the valid-time from crux/q? We need to add something like an :update-at key to all our models and we wanted to avoid to remember the extra call to crux/entity-tx We were also thinking of setting :valid-time and :update-at at transaction time instead but we are not sure yet about the consequences

refset00:08:50

Hi @U0C8489U6 there's no built-in way to return this information inside the query, but you can do it like this https://gist.github.com/refset/385d6dcfb66772aa1ec46fc20a49c633 Making valid time first-class in the query language is firmly on the roadmap though 🙂

👍 3

richiardiandrea00:08:15

Oh this is nice indeed, forgot I can include arbitrary code in the query

🙏 2

richiardiandrea15:08:30

Ah, I am a big fan of pull so I am not sure that's going to work here, thanks though

refset21:08:12

Hmm, yeah, adding a custom parameter hook into the eql would be nice but you can't do that currently

❤️ 2

richiardiandrea16:07:59

@U899JBRPF would that approach above in the gist have a big impact performance-wise? We ended up using an :updated-at key in some of the entities but now I am re-considering that approach

refset16:07:03

Hey @U0C8489U6 the performance should be pretty decent (though not quite as optimal as if it were a native lookup). Perhaps a little bit slower than a simple manual :updated-at lookup, but it certainly shouldn't present any serious kind of bottleneck.

👍 1

sheluchin19:08:00

If using maps as :crux.db/id values, like :crux.db/id {:foo/id 1}, is there some way to query for all records that have some such id? Something along these lines:

(let [node sheluchin.server.db.mounts/crux-node]
    (sheluchin.server.db.queries/query node
     '{:find [foo]
       :where [[foo :crux.db/id {:foo/id id}]]}))

richiardiandrea20:08:09

I think you will have to specify the full map as entity id - something like:

[foo :crux.db/id {:foo/id 1}]

richiardiandrea20:08:59

if you are going for a "list all" without caring about that specific id, the pattern we are using is to have a my-company/type that would allow us to fetch all the entities for a given keyword

sheluchin20:08:20

So you just include that field in every document and use it to filter for any given type?

richiardiandrea20:08:26

yep

richiardiandrea20:08:32

it's also mentioned in the docs but now I cannot find the reference

sheluchin20:08:51

I wonder if there are any downsides to using metadata like that instead of querying the actual data in some way. Seems like a simple enough approach.

sheluchin20:08:42

I think such an example is included in the space tutorial. Maybe that's where you saw it. I just wasn't sure if that was a simplified example or a common pattern to use in real applications.

richiardiandrea20:08:10

I vaguely remember that benefits outweigh the costs - probably the core team can explain this better but what you also gain is that now your entity type is not "set in stone" - it's just data and can evolve over time

👍 2

✔️ 3

2021-08-20

Channels