I don’t have a direct link handy, but piping was discussed on SQLite’s mailing list when BigQuery released their pipe, I’ll post it if I can find it.
I believe it’s in this thread SQLite User Forum: Interesting paper from Google on pipe syntax on SQL linked in this thread: SQL pipe syntax available in public preview in BigQuery | Hacker News
This thread itself shows that naming an Elixir package the same as an other language is a very bad idea. When does someone talk about the package when they write ”SQL”? When about the language?
I must admit I haven’t been able to follow the thread just because of that.
For what it’s worth there is precedent for this pattern in OTP, json, ssl, ssh, ftp and many more.
Maybe we need a contest at some point in the future for the person who comes up with the best name.
The one and only reason I would abstain from a generic name like sql would be that I don’t trust my planning skills enough to know whether a project’s scope might not change in the future, making the name an inconvenience or misleading.
@Schultzer I’ll have my SQLite thing in the open very soon (a few weeks more; and technically it’s open and working even now but it was a quiet launch and there are still 1-2 features I want to put in before I make an announcement). What would you need from my raw library (no Ecto integration yet) so yours can work with it? We should likely take this to DMs but just giving you a heads up.
We’ve happy to announce the release of 0.5.0, packed with performance and compile time improvements.
In this release we’ve started to move away from using Ecto and it’s pool, with our new PostgreSQL driver and connection pool, where we see 1.5x to over 100x depending on workload and concurrency, and this is only the begining in our next release we’ll expecting more performance improvements when we’ll implement decoder/encoder specialization.
We’re planning to release repo with a new phoenix application with phx.gen.auth, to showcase how SQL would look, Phoenix and phx.gen.auth has been used extensively to validate the new pool and transactions works reliablie. This also means that when you run tests with SQL, the production pool is used and your not testing against a sandbox which is what Ecto does.
Please see the sql/CHANGELOG.md at v0.5.0 · elixir-dbvisor/sql · GitHub for all details.
Because postgrex and db_connection cannot do what we do, and it won’t be able to do specialization.
Our pool design is fundamental different and opens up for low latency at high concurrency with scheduler affinity in a scheduler pool. AFAIK this is a first on the BEAM in regards to database connection pools.
After a further inspection, I love the idea and might even use the library in my personal projects. I’m wondering where the composability is because I didn’t see any examples. Can I build up where clauses like I can with Ecto? For example, if I’m using GraphQL and want to compose a query based on the context. Also there are no examples for anything besides simple selects. Can I insert and update records?