456 karma · joined November 22, 2015
[1]: https://www.reuters.com/technology/openai-tells-investor-not...
``` The teams that succeed don’t just throw SQL schemas at the model. They build:
Business glossaries and term mappings
Query templates with constraints
Validation layers that catch semantic errors before execution ```
Unfortunately, the mixing of fluffy tone and high level ideas is bound to be detested by hands on practitioners.
If you want to see the other style of writing in Rushdie, I can suggest Shalimar The Clown or The Ground Beneath Her Feet. But these are nowhere near as grand as Midnights Children.
In either category, a fair amount of interest in history helps to enjoy his books.
PromptQL is a programmatic approach to LLM tool composition which has shown remarkable improvement in accuracy (~2x) and repeatability (~4x) when compared to traditional tool calling and chaining approaches.
Fundamentally, PromptQL separates the creation of a query plan from the execution of the query plan. PromptQL uses the LLM to first create a program to compose the different tool calls hence avoiding the challenges with in-context tool chaining like accuracy, repeatability and context limits.
Fun fact the cover image if this edition was kind of a decoy (perhaps to accentuate the shock): https://www.newyorker.com/magazine/1946/08/31
This. Not sure why RAG triggers vector search for everyone. Retrieval Augmented Generation is as generic as it can get.
To me it seems a more risky use-case since you don't have control/observability over what an untrusted user is asking for?
Hasura is a venture-backed open-source and Cloud technology company that makes your data instantly accessible over a real-time GraphQL and other API technologies. Hasura connects to your databases, REST servers, GraphQL servers and third party APIs (eg: Stripe, Salesforce) and provides a unified API across all your data sources.
Hasura is looking for a Senior/Staff Software Engineer with proficiency in Rust to become part of the core engineering team. In this position, you will work on developing innovative features on the core product. We are writing the core components of the product in Rust to accelerate feature velocity hence Rust expertise is required. This is an exciting time to join this effort in the early stages.
If you are interested, please apply at: https://hasura.io/careers/?jobId=FjqRMQHVXKnW
Also, there is another interface for real-time subscriptions called live queries which might be more appropriate depending on the use-case: https://hasura.io/docs/latest/subscriptions/postgres/index/#... .
We have 2 interfaces for real-time subscriptions: live queries and streaming. The former has been around for few years now. You can read more here: https://hasura.io/docs/latest/subscriptions/postgres/index/#...
Hasura uses a novel way of batching similar parameterized subscriptions together and then polls under the hood. This means that if there are 1000 subscribers of similar type of query, then underneath Hasura will only make a single query to Postgres (or few queries depending on the batch size). This approach, which we call "multiplexing" in short, scales really really well. And is also the simplest way to get live updates for _any_ query, no matter how many joins, etc.
We talk more about this approach (and comparisons with other approaches), and benchmarks in this post: https://hasura.io/blog/1-million-active-graphql-subscription...
You could! But you would need ideal concurrency semantics.
> I didn't find anything Postgres specific other than maybe "SELECT FOR UPDATE SKIP LOCKED" which you can do without
You mean using some equivalent way to achieve "SELECT FOR UPDATE SKIP LOCKED" ?
Amazing stuff.
Do you have any references which shows this behaviour? Or a way to reproduce it?
(I’m from Hasura)
You can extend business logic in Hasura in a number of ways, including (but not exclusively) ones that work well with serverless and async architectures. Other examples follow:
1. You can extend it by adding business logic in the database via user-defined functions. Eg: You want a fulltext search or a PostGIS function that is better off in the DB anyway.
2. You can bring your own GraphQL server with custom resolvers and Hasura will merge them into its own API and let you “join” across them as well.
3. You can bring REST APIs and add graphql types for them in Hasura and use it as custom resolvers that extend the schema as well.
Hasura’s key value add is an instant GraphQL API backed by your own data-sources (database, GraphQL, REST) and then a fine-grained authorization system on it.
Like Nikolas said, very different from Prisma. Hasura aims to add value as “infrastructure” by guaranteeing performance and security where as Prisma is like an ORM/database toolkit.
We already support user defined PG functions to be exposed as graphql queries so this is a natural extension.
I agree 100%. The hardest general books are probably in the area of philosophy. My recent fav: The Logic of Scientific Discovery by Karl Popper.
I think it would be more correct to just say that GraphQL encourages queries as first class object as it exposes the entire schema and allows for granular querying.
Implementing it by composing REST APIs is, well, an implementation detail. There are other ways to do it too.
This thread is quite timely as we recently published a post about this here: https://hasura.io/blog/fast-graphql-execution-with-query-cac...