a-type
commented
1 month ago In order to do something like this Verdant needs a concept of "app ID" as metadata for libraries.
That's because two libraries from two different apps could both have a collection with the same name, but different indexes. To properly register index schemas, the key would need to be [appId, libraryId, collectionName].
A few other questions remain... what happens if the client schema changes so that the server indexes aren't valid anymore? At minimum, any index should have nullability I guess.
But at this point I'm wondering if a lightweight server-side client running as a sidecar would be better, or something in that vein. Maybe overkill?
This is relevant to WishWash... the app organizes data with items being their own documents, looked up together by listId index. When going to get a snapshot of the 'list' on the server, there's no way to tell which items match the index.
Server side querying would be a huge shift in how the server works and what assumptions it makes. Not even sure how to approach it.
Perhaps you can maintain a 'server indexes' mini-schema. Register indexes for collections. The server handles migrating the SQL schema to include a column for each index in a special table. Anytime ops are stored the row is recalculated. You can use the table to lookup the matching docs.
(Can't store it in baseline as baselines don't exist until rebases. Don't have to recompute on rebase as it should be the same)
Feels fragile to have userland schemas driving the database's schema, but if isolated to this one table at least the blast radius is contained if something goes wrong.