rfcs VS partiql-lang-kotlin

Search it is! I could implement search that searches for exact tokens in the tools the author connected and the README, but I want to wait for anything more until EdgeDB releases its full-text search solution https://github.com/edgedb/rfcs/blob/master/text/1015-full-te...

I actually had a feature in mind where people could vote on starters they want and others could build them out and list them for free or a price. Do you think that would fit your needs and is there anything in particular you'd want to see in a feature like that?

Replied on Twitter!

> I see EdgeDB as primarily focused on transactional queries, whereas PRQL is very focused on analytical queries.

That's true to an extent currently, but we actually envisioned EdgeQL to be a capable analytical query language too. We'll release EdgeDB 2.0 in a couple of weeks and it will feature a powerful GROUP BY statement (read more about it here [1]) and in 3.0 we might ship window functions (or some equivalent).

With all that said PRQL looks cool!

[1] https://github.com/edgedb/rfcs/blob/master/text/1009-group.r...

>> We shall do better than SQL

> The EdgeQL language looks cool, and I'm sure querying via a graph structure makes certain problems easier in some use cases. However as much as people have complained about SQL, it's just so ubiquitous there needs to be a very good reason to switch away from it. Not having to write joins isn't really a good enough reason, in my opinion.

Oh, it goes much deeper than not writing joins. There's no single ORM out there that can implement a TypeScript query builder like ours, see the example in [1]. This is only possible because of EdgeQL composability, but that composability required us to rethink the entire relational foundation.

> > The true source of truth

> I'm not sure why this means EdgeDB is better. <..>

This section implies that EdgeDB's schema allows to specify a lot of meta / dynamically computed information in it. And soon your access control policies. Take a look at the work-in-progress RFC [2] [3] to see how this is more powerful, then say, Postgres' row level security.

> > Not just a database server

> It sounds like they have a solid client, which is awesome.

Also lightweight connections to the DB so that you can have thousands of concurrent ones without load balancers, built-in schema migrations engine, and many other things. In fact we have so much that it's challenging what to even highlight in a blog post like the 1.0 announcement.

> Cloud-ready database APIs

> This used to be true, but is definitely no longer true. Cloud-native databases are everywhere and incredibly common. See any major cloud, https://www.cockroachlabs.com/, or any of the tons of other database solutions.

Not to pick on CockroachDB (they have an amazing product and company, we love them), but you should benchmark local install of Postgres and Cockroach to see yourself that scalability still has a significant cost in performance.

[1] https://www.edgedb.com/blog/edgedb-1-0#not-just-a-database-s...

[2] https://github.com/edgedb/rfcs/pull/49

[3] https://github.com/edgedb/rfcs/pull/50/files

EdgeQL is getting support for generic partitioning/aggregating `GROUP` very soon [1], so we are giving some love to the analytical side of things too :-)

We definitely need more collective effort put into "Better SQL", so PRQL is a welcome sight!

[1] https://github.com/edgedb/rfcs/blob/21e581a188715c6ff82944b6...

Ion is heavily used on the retail side of Amazon, but it's only recently started to appear in AWS products.

AWS is starting support PartiQL (https://partiql.org/) queries in some places and PartiQL uses Ion's type system internally.

Yep, that's exactly the vision here. One of the biggest sources of precedent and inspiration for us here is https://partiql.org/ which is picking up a fair bit of traction across AWS. Also see https://rockset.com/

QLDB allows you to create a ledger that acts similar to a schema or table space in a traditional database. Once you've created this ledger, you create a table through the SQL-like query language PartiQL that also enables you to interact with the data.

PartiQL[0] is an open source library that is a superset of SQL that I really like. It supports querying nested structures inside columns, so if a column contains some JSON data you can use the standard dot notation to query nested JSON data directly

[0] https://partiql.org/

PartiQL was introduced to AWS DynamoDB, with AWS making the announcement in 2020 making the life of developers easier, with the comfort of executing commands similar to SQL.

I haven't tried it, but I'm pretty sure the problem is that timestamp (and it's various capitalizations) is a keyword in PartiQL (https://github.com/partiql/partiql-lang-kotlin/blob/master/lang/src/org/partiql/lang/syntax/LexerConstants.kt#L221). To get it to be interpreted as an attribute name, you need to enclose TimeStamp in double quotes.