Wouldn't you wanna save the json even if the structure is incorrect?
Pg_jsonschema – JSON Schema Support for Postgres
31–40 of 46 posts
Re: Pg_jsonschema – JSON Schema Support for Postgres
#32This looks rad.
Re: Pg_jsonschema – JSON Schema Support for Postgres
#33Wouldn't you wanna save the json even if the structure is incorrect?
If you want that behavior, just don't use json schema.
Re: Pg_jsonschema – JSON Schema Support for Postgres
#34I've tried to use JSON Schema and the big gap I couldn't figure was how to handle polymorphism.
That is, if I have a case where object
{
"Foo": {
"Type":"Fred"
"Bar":1
"Baz":2
"Quux":2
}
}
{
"Foo": {
"Type":"Waldo"
"Bar":1
"Corge":2
"Xyzzy":7
}
}
I did a hack by multiplexing the types into a child-object, but that was ugly and clumsy.
In XSD or any statically-typed programming language I could handle this trivially using types and polymorphism, because "Fred" and "Waldo" would be different types.
But I can't figure out how to do that in Json Schema.
Re: Pg_jsonschema – JSON Schema Support for Postgres
#35I've tried to use JSON Schema and the big gap I couldn't figure was how to handle polymorphism. That is, if I have a case where object { "Foo": { "Type":"Fred" "Bar":1 "Baz":2 "Quux":2 } } and the object { "Foo": { "Type":"Waldo" "Bar":1 "Corge":2 "Xyzzy":7 } } are both valid, without just allowing any object members or allowing the union of their members. I did a hack by multiplexing the types into a child-object, b…
IIRC that's what oneOf is for. i.e. a discriminated union / sum type. My experience with oneOf is that tooling support for it is terrible.
Re: Pg_jsonschema – JSON Schema Support for Postgres
#36PG community had a similar patch, which got reverted from PG 15 on the last minute: https://www.depesz.com/2022/04/06/waiting-for-postgresql-15-...
this would be our preference. we'll try to support this for the next commitfest, and if it gets merged then we will deprecate our extension in favour of the native solution.
Well written article! Also very glad to hear your approach to support the native implementation. For all of our projects when we're integrating external services we usually keep the relevant original JSON responses as a jsonb as kind of a backup. Next to that we extract the data we'll be using to queryable data. To be able to use those "dumps" directly would be a nice thing to have.
Re: Pg_jsonschema – JSON Schema Support for Postgres
#37I've tried to use JSON Schema and the big gap I couldn't figure was how to handle polymorphism. That is, if I have a case where object { "Foo": { "Type":"Fred" "Bar":1 "Baz":2 "Quux":2 } } and the object { "Foo": { "Type":"Waldo" "Bar":1 "Corge":2 "Xyzzy":7 } } are both valid, without just allowing any object members or allowing the union of their members. I did a hack by multiplexing the types into a child-object, b…
IIRC that's what oneOf is for. i.e. a discriminated union / sum type. My experience with oneOf is that tooling support for it is terrible.
Ah, I didn't realize you could use oneOf with refs or objects, I've only ever seen it used with primitives. Thanks!
Re: Pg_jsonschema – JSON Schema Support for Postgres
#38[deleted]
Re: Pg_jsonschema – JSON Schema Support for Postgres
#39Earlier quoted context omitted.
Hasura is also FOSS
Hasura is open core. Given the massive price increase they just did for their hosted version, I’d expect more and more future features will not land in core at all, to push people to pay.
Hasura CEO here. Totally hear you.
We're working on a new serverless infrastructure layer that'll make the pricing better for users compared to a DIY API server or to a self-hosted Hasura.
It's a significant engineering lift on our side - at its core we're engineering Hasura to achieve 90%+ infrastructure utlization (no cold-start, sub-millisecond auto-scaling), and that's what will allow us to do this.
Not there yet, but we'll be demo-ing and talking about the engineering at HasuraCon in June!
Re: Pg_jsonschema – JSON Schema Support for Postgres
#40Earlier quoted context omitted.
Hasura is open core. Given the massive price increase they just did for their hosted version, I’d expect more and more future features will not land in core at all, to push people to pay.
It’s already quite bad unfortunately. Both support for read replicas and metrics(!) are not in the open source version. They have a prometheus exporter but not on free, afaik. I was also concerned with people reporting memory consumption/leak issues, as I’m planning to have lots of subscriptions. I don’t know haskell well enough, but from the outside it does match the symptoms of having dug themselves into an archite…
(from Hasura)
Scaling subscriptions is hard, but we work with our users/customers at scale to make sure settings are tweaked correctly.
We have users running 100k - 1M concurrent users in production for live-event type platforms. It's not completely trivial to benchmark and setup because query patterns, streaming vs live queries etc have an impact, but it works very reliably. No missing events, no problems disconnecting/reconnecting, no need for sticky sessions and so on.
An initial POC benchmark [1] should be a quick affair so if you're trying it out and run into any problems, please hit me up! Email on my bio.