Querying multiple IDs
Quick question - is there planned support for
IN query filter, e.g. passing a list of IDs to the query filter4 Replies
Most of the time people tackle these as a "join", see the second code snippet here:
https://docs.convex.dev/database/reading-data#more-complex-queries
If your ID is in a field other than _id, you can replace the
db.get with db.query("tableName").withIndex("myIndex", q=>q.eq("someIdFieldName", id).unique())Reading Data | Convex Developer Hub
Query and
Yeah I mean it just feels like a join with a promise.all is a little overkill.
I'm not clear on how these queries run in convex architecture, but it feels awkward to me to create many queries when you can have one relatively simple one
The JS code runs close to the DB. You can think of it as a UDF or an implementation of the database engine itself.
And you can implement helpers to avoid repeating the same patterns, as showcased here:
https://stack.convex.dev/functional-relationships-helpers
Functional Relationships: Helpers
In this post, we’ll look at some helper functions to help write code to traverse relationships in a readable, predictable, and debuggable way.
The
Promise.all part can feel overkill on the surface.
In more traditional systems, you have a backend server talking to a potentially far-away database server somewhere. So many of us have been trained to think about sending "as big a query as possible" to the database. We often do this by writing a complex join to reduce the network back-and-forth overhead for each lookup from the database server.
What may take a minute to "click" about Convex is that your backend functions actually run really really close to your database. So, the overhead of looking up more things from the database is pretty low, to the point that you likely never need to think about the cost of querying multiple records separately.
This is one of Convex's super cool wins by being an all-in-one platform.
If you want to read more about our philosophy around this you can read this: https://stack.convex.dev/not-sqlIt's not you, it's SQL
SQL has been a part of computing for a very long time, and SQL-based database systems underly most of the world's applications. But recently, develope...