#is it possible or advisable to create custom query operators?

16 messages · Page 1 of 1 (latest)

pale gazelle
#

I'm attempting to write a DB adapter for PocketBase. I've got it mostly working (https://github.com/nathanstitt/pbtsdb) but am having difficulties supporting the PocketBase expand https://pocketbase.io/docs/working-with-relations/#expanding-relations which is how it handles fetching associated records in one request.
It seems like ideally we could write a query like:

 useLiveQuery((q) => q.from({ books }).expand('authors'))

However, maybe that doesn't fit into the design of queries and they should be adapter agnostic? I can of course set the expand in the queryFn of the collection, but that means that all requests would use it and it would be nice to be able to opt-into the expanded request only when needed.

inner pivot
#

on the expand — yeah if you want to do cross-collection optimized loading — that'd be a layer above DB

#

you could generate the collections for your schema and then e.g. when a collection loads, you could use the expand and feed in the extra data loaded into the right collections

#

but db itself can't really track these sorts of relationships & optimized batched loading

pale gazelle
#

Oh wow I think we both started this roughly at the same time, I def didn’t see that when I started this. I’ll take a close look at what he’s doing , thank you.

My concepts of expand should funnel the associated records into the related collection, which I do have working just not on a per query basis. For that I think I’ll need to add a custom operator but it’s not clear if that’s possible

inner pivot
#

Did you see our recent query-driven sync release?

#

With it, query predicates can be pushed into the collection to load

#

You could then send those up a level to combine the loading somehow

pale gazelle
#

yes, i just implemented support for most of the query operators in 0.5, and am playing with add a expand query operator that can be passed down to that now but then thought that maybe that wasn't the best approach, hence this post 🙂

inner pivot
pale gazelle
#

oh yes, i didn't think it would be part of tanstack db, it would be imported from the pocketbase package. Getting the types correct will be tricky though, and DB doesn't seem to be setup to make implementing a custom operator easy (or maybe even possible)

inner pivot
final swift
inner pivot
pale gazelle
#

oh yah completely understandable! DB is looking really nice though, i've transitioned a react-native expo project from using useQuery/useMutation to it and its so much nicer