I agree with lots of the points here. However one of the great strengths of the SQL family is the FOSS history. I doubt something proprietary is ever going win everyone over. At least I hope not.
It's not you, it's SQL
51–60 of 84 posts
Re: It's not you, it's SQL
#52Optimistic concurrency control is mentioned as a feature of Convex, the advertised product. But OCC is a common concern and has been for ages. In Java, the JPA standard specifies the @Version annotation which enables OCC on entity objects and it's implemented by the usual suspects like Hibernate. It's been around for at least a decade so I'm struggling to understand why this is being presented as some big innovative…
Article author here.
It's not new "in the world", but often new to our users, who understand it less intuitively than pessimistic locking.
Unless they're using Haskell or probably other very exotic environments with strict understanding of mutability and so on, they know Mutexes but not STM or other OCC patterns. So we lean heavily on explaining it. Not because it is original, but because it is unfamiliar.
Re: It's not you, it's SQL
#53Wow, this is written by an early mentor of mine who introduced me to CouchDB and MongoDB circa 2008! I went on to take MongoDB to Urban Airship (now Airship), make a complete mess out of things (lots of evidence of that on HN even), and eventually port it all to a Postgres cluster. Meanwhile jamwt went to Dropbox and ended up managing thousands of SQL instances of his own! And now both of us are back on non-SQL datas…
Hi there Michael! We continue to love nomad. SQL is the C ABI of querying for sure. BI tools will never adapt to use Convex directly, and nor should they. So... yes, Convex actually had a prototype SQL adapter for the read side of things back in the early few months when we were figuring things out. Convex's read semantics are very compatible with SQL. We've kept this adapter on ice in part because of point #3 in the…
Hello!
> Convex actually had a prototype SQL adapter
Ha, this sounds like the heaps of scripts we Nomad developers have lying around for converting ad hoc bits of Nomad state to sqlite for debugging particularly stateful problems.
> So the current recommended practice is use our Airbyte Egress connector
Ah this is where we would like to end up with Nomad's event stream API: https://developer.hashicorp.com/nomad/api-docs/events#event-...
Sadly we've been unable to identify that First Sink to implement and open source. It's a lot of work to build and maintain production quality connectors, so it would be nice to do just one like your Airbyte Egress. This is an area where Nomad's onprem nature makes it hard to pick one solution that will work for a wide number of users. Someday!
Re: It's not you, it's SQL
#54I agree with lots of the points here. However one of the great strengths of the SQL family is the FOSS history. I doubt something proprietary is ever going win everyone over. At least I hope not.
Article author here.
Agree this is a necessary part of the change. Convex is working on our OSS strategy this year. Thanks for the feedback!
Re: It's not you, it's SQL
#55Earlier quoted context omitted.
> Discoverability can be quite lacking. A richer type system would help there, but to my knowledge this isn't offered by any major relational DBMS.
https://www.postgresql.org/docs/current/sql-createtype.html Postgres allows you to define custom types at least; making some enums or composites might give you some measure of sanity..?
Thanks.
The Ada programming language is known for encouraging use of specialised numerical types, where the range can be expressed and automatically checked at runtime, and the compiler can help protect against nonsensical comparisons or arithmetic. At a glance I think Postgres range types offer something similar. Presumably strong typing could also be achieved with Postgres composite types (of just one member).
It would be useful to have such checks so that a nonsensical comparison like WHERE person1.height = person2.net_worth would result in an error. Presumably it could also be helpful for autocompletion.
Re: It's not you, it's SQL
#56I agree with lots of the points here. However one of the great strengths of the SQL family is the FOSS history. I doubt something proprietary is ever going win everyone over. At least I hope not.
SQL took a long winding road to reach the FOSS friendliness it has today. Its history is littered with patent, copyright, and trademark disputes. Not to mention widely varying implementations and the continuing lack of a crossplatform wire protocol or standard interface. Proprietary incumbents still dominate huge sectors of the SQL landscape and pose compatibility and intellectual property issues for FOSS implementations.
I think any SaaS APIs that reach any degree of widespread adoption eventually get OSS implementations (eg S3's API is widely supported by FOSS and proprietary implementations). This evolutionary path is awfully similar to SQL's for better and/or worse.
Re: It's not you, it's SQL
#57Earlier quoted context omitted.
A database system could implement a feature that automatically uses the foreign key to join to a table. Maybe some RDBMS out there does this. For example, you have a many to one relationship between posts and users. Instead of this: select * from user as u join post as p on p.user_id = u.user_id; You could do: alter table post add constraint fk_user_id foreign key (user_id) references user.user_id; select * from user…
SQL already covers this use case with the `using` keyword. But you need to specify the shared column name. If you didn't need to specify the column then adding a new foreign key between the tables would make existing queries ambiguous and break backwards compatibility. See: https://www.postgresql.org/docs/current/queries-table-expres... .
Using is a bad standard. It doesn't do the obvious thing (that is following foreign keys), it requires a heavy amount of bad conventions, it fails for the not too rare case where you need more than one FK between the same two tables, and if you go strictly with the standard (good for Postgres that it doesn't), it breaks the table-aware semantics of column names.
Meanwhile, the obvious natural way to make joins isn't available.
Re: It's not you, it's SQL
#58> Tab! Tab! Tab! PostgreSQL demonstrates its field autocomplete feature. SELECT preceeding FROM is such a thorn in the side. :(
I wish SQL did not require a comma between items after the SELECT and before the FROM. We don't need commas in between joins. I feel like someone could write a way to parse queries so that it isn't needed. Can you imagine how much time and effort that would save people? Edit: You do need commas in ORDER BYs, that slipped my mind when typing out this pet peeve of mine.
You can use commas between tables perfectly well. The `join` token just has the same role as the comma, making it redundant.
Re: It's not you, it's SQL
#59Earlier quoted context omitted.
An ORM allows you to encode a relationship once then use it for many different queries, I think that's the idea.
But a view also does that? Like, if you want to assemble information about a user from several different tables, you can have a view that does the join for you.
Sure, but people never use those. Also it gets back to the discoverability issue. The ORM documents relationships with the rest of the model code, if you have a poorly named view in a large, complex schema it may be hard to find. You could reinvent the wheel easily.
Like everything with SQL, you can solve the problem but sometimes the solution isn't elegant. People want elegance.
Re: It's not you, it's SQL
#60The article presents the move from the old, doddering SQL to the newer, better NoSQL - but the hierarchical database model actually _predate_ SQL. The first databases like IBM's IMS were hierarchical a lot like Mongo is: Codd was actually trying to address the problems with that model when he created the relational model.
Article author, here. Good point -- but the article actually proposes document relational, not hierarchical. Relational is definitely good!
It vaguely references it, doesn’t explain what the data model it is proposing actually is in concrete terms. It gives some API examples, but nothing that tells me what is different between it and the data model of any of the major (Object) Relational DBMS’s with an appropriate host-language client adaptor except that the client library exists only for TS and the type system is designed to be 1:1 with TypeScript. And the data model arguments (except for the client-language type equivalency for TypeScript) are all exactly the classic arguments for ORDBMS’s over classic RDBMS’s, which I guess “won” to the extent that many major DBMS are ORDBMS’s, but kind of lost in that almost everyone, even using them from an OO host language with the kind of deeply OO code that was in fashion a decade or two ago but is falling out of fashion these days, uses mostly just the RDBMS features, and it works pretty well because of the universality of the relational model.
Really, the big thing that I see here is the transaction retry logic, which (if the writes in your transaction depend only on the reads on not side effects, which you’d need to declare) would be a nice feature for any db engine, and (if the side effects are packaged together in a safe way with the relevant reads and writes, which can be more general) would also be a nice feature for a high-level db client library, independent of backend. But that’s a pretty thin reed to hang a dependency on a proprietary SaaS solution over, say, Postgres on.