101–110 of 166 posts
I'm surprised that none of the examples on Github or the website deals with join. I eventually found some in the "book" here: https://prql-lang.org/book/transforms/join.html from employees join side:left positions [id==employee_id] turns into SELECT employees.*, positions.* FROM employees LEFT JOIN positions ON id = employee_id I would love to see joins worked into the main learning examples. Without join, the exampl…
I recently started implementing the Postgres protocol in Rust ( https://github.com/dmeijboom/postgres-conn ). So I guess I’ll be experimenting with creating a Postgres proxy which translates PRQL on-the-fly.
I see that the JavaScript package is at [1] and it's implemented by compiling the Rust code to WASM. That should eventually make it pretty easy to run it. It has a typescript definition file, but it looks like it's autogenerated and a bit clunky. You get back a CompileResult and have to call free() explicitly, it seems? That doesn't seem very idiomatic for JavaScript. Also, the links to the documentation and examples…
That's true - the package is auto-generated using [wasmpak]( https://github.com/rustwasm/wasm-pack ), that's why TypeScript definitions are clunky. I did the initial prql-js release and I'm actually not sure about the free() issue you are talking about. We are currently working on compiling it for both Node.js and the browser target, and would be happy to see some advice if you are familiar with WASM!
export function compile(s: string): CompileResult;
export class CompileResult { free(): void;
readonly error: CompileError | undefined;
readonly sql: string | undefined;What is the purpose of the free() method?
(I'm a co-founder)
Earlier quoted context omitted.
It's not straightforward to do polymorphic joins: one common pattern is to have child tables for each case of the union, but there's no integrity constraint such that each parent must only have one child, e.g. CREATE TABLE schools (id SERIAL PRIMARY KEY); CREATE TABLE colleges (id INTEGER NOT NULL REFERENCES schools (id)); CREATE TABLE high_schools (id INTEGER NOT NULL REFERENCES schools (id)); How can you ensure tha…
A combined approach works if want to encode the exclusive constraint: CREATE TYPE school_type AS ENUM ('college', 'high_school'); CREATE TABLE schools ( id SERIAL PRIMARY KEY, type school_type, unique (id, type) ); CREATE TABLE colleges ( id INTEGER NOT NULL, type school_type default 'college', check (type='college'), foreign key (id, type) references school(id, type) ); Ya, the syntax is annoying and repetitive. It…
Thanks, I've frequently wanted a query language that was designed after the 70s. The ideas are sound, but a modernized syntax with variables to reuse subqueries would be lovely. This looks like it. I noticed one issue though... please don't copy the prefix of f-strings! That only exists because Python boxed itself in and it was literally the only ascii syntax left that could be used for string interpolation. It's mil…
Interesting suggestion. We added f-strings because we already had s-strings (pass trough to SQL) and r-strings (for raw multi-line text). And would you rather see "My {name}" or "My ${name}"? I personally dislike the $ prefix for all variables and interpolations...
Earlier quoted context omitted.
What is annoying about implementing something like this in a relational database?
It's not straightforward to do polymorphic joins: one common pattern is to have child tables for each case of the union, but there's no integrity constraint such that each parent must only have one child, e.g. CREATE TABLE schools (id SERIAL PRIMARY KEY); CREATE TABLE colleges (id INTEGER NOT NULL REFERENCES schools (id)); CREATE TABLE high_schools (id INTEGER NOT NULL REFERENCES schools (id)); How can you ensure tha…
Do you have any real world scenarios where you've faced this problem?
In your example, you wouldn't model it like that. A school just needs an attribute that identifies the type of school (high school or college), and other attributes that would be common to both.
I'm sure there's lots of examples but it's late and I'm struggling to think of one that a good normalized data model couldn't handle.
Thanks, I've frequently wanted a query language that was designed after the 70s. The ideas are sound, but a modernized syntax with variables to reuse subqueries would be lovely. This looks like it. I noticed one issue though... please don't copy the prefix of f-strings! That only exists because Python boxed itself in and it was literally the only ascii syntax left that could be used for string interpolation. It's mil…
> a modernized syntax with variables to reuse subqueries would be lovely. CTEs provide this functionality already, don't they?
I also recommend looking at EdgeQL -- https://www.edgedb.com/showcase/edgeql -- a new query language aimed to eliminate some of the SQL quirks. (I'm a co-founder)
Possibly our focus is a bit different — I see EdgeDB as primarily focused on transactional queries, whereas PRQL is very focused on analytical queries. PRQL doesn't do quite as much — e.g. we don't model the relationships between entities, which is less functional but more compatible.
Feel free to reach out on Twitter if you think there's some way of us collaborating, or if you have any feedback or guidance for us.
Here's one suggestion: SQL tediously requires specifying the equality condition on joins, when 90% of the time you just want to join on the fk defined between the tables. from a join b should implicitly join on the FK if no condition is given. It would require knowledge of the schema. I don't know if this is possible in PRQL, or if the transpilation to SQL has to be stateless.
But I think that's a shortcoming of the client tool, rather than the language.
If SQL tools auto completed the join conditions as best as they could it would probably be a great help.