3 ms·
Sounds like the goal here is to augment search with a sort of query language. One that's more structured than a mere list of keywords? Ribbing aside, the "reth
by 10000truths 4mo ago
Sounds like the goal here is to augment search with a sort of query language. One that's more structured than a mere list of keywords?
Ribbing aside, the "rethinking" here sounds a lot like an AI-specific spin on the "bring the code to the data, instead of data to the code" paradigm. I imagine that the same multitenancy caveats of allowing arbitrary user-defined queries against a relational database (execution limits, access controls, etc.) will apply here as well.
- esafak 4mo agoI don't understand why you wouldn't simply provide SQL with requisite security precautions. Do you really need more?
- tomjakubowski 4mo agoA duckdb backend that can query something like Sourcebot would be swell.
- kaiokendev 4mo agoGoogle Search used to essentially be this, then they had to tack on finnicky AI systems to handling the parsing of unstructured queries, and that was a cost/time sink that swung the pendulum over to fully AI-native search. This is the pendulum swinging back the other way with a new generation of UX designers. And it'll swing back eventually, too.
- 10000truths 4mo agoSQL was designed with tabular data and a relational model in mind, and free-form documents have neither of those properties. You can shoehorn full-text search functionality into SQL - that's what the likes of MySQL/PostgreSQL/SQLite do - and it's good enough in cases where search isn't a core competency. But it's awkward to use and subject to the limitations of a syntax catered to declarative queries and rigid schemas.