partiql-lang-kotlin VS logica

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.

If you're interested in this I would also recommend you check out Logica[0], which is a datalog-like language that is explicitly made to compile to SQL queries.

0: https://logica.dev/

> I guess the intention is to be better than SQL but then I was left with "under which circumstances?"

Excellent question.

Two of the most common use cases for databases are "transactional processing" (manipulating small numbers of rows in real time) and "analytical processing" (querying enormous numbers of rows, typically in a read-only fashion).

SQL is generally fine for transactional workloads.

But analytical queries sometimes involve multi-page queries, with lots of JOINs and CTEs. And these queries are often automatically generated.

And once you start writing actual multi-page "programs" in SQL, you may decide that it's a fairly clunky and miserable programming language. What Datalog typically buys you is a way to cleanly decompose large queries into "subroutines." And it offers a simpler syntax for many kinds of complex JOINs.

Unfortunately, there isn't really a standard dialect of Datalog, or even a particular dialect with mainstream traction. So choosing Datalog is a bit of a tradeoff: does it buy you enough, for your use case, that it's worth being a bit outside the mainstream? Maybe! But I'd love to see something like Logica gain more traction: https://logica.dev/

Interesting; a Google engineer previously published a Datalog variant for BigQuery: https://logica.dev/

This new language seems similar to differential-Datalog (which is sadly in maintenance mode): https://news.ycombinator.com/item?id=33521561

Looks pretty cool. I'd be interested if the README had a comparison with Google's Logica (https://github.com/EvgSkv/logica)

Oh wow that is neat!

And yes, this kind of thing is why datalog is a lot more amenable to fast query plans & runtimes than prolog. This part is especially cool: https://github.com/EvgSkv/logica/blob/main/compiler/dialects...

Google new programming Language that compiles to SQL (Support BigQuery and Postgres) feels very exciting. Blog: https://opensource.googleblog.com/2021/04/logica-organizing-your-data-queries.html Github: https://github.com/EvgSkv/logica

Going to be? It already is. In fact, one thing the article misses is right there at the bottom of the project page: