duckdf VS ecto

Quite a while ago, when duckdb was just a duckling, I wrote an R package that supported direct manipulation of R dataframes using SQL.[1] duckdb was the engine for this.

The approach was never as fast as data.table but did approach the speed of dplyr for more complex queries.

Life had other things in store for me and I haven’t touched this library for a while now.

At the time there was no Julia connector for duckdb, but now that there is, I’d like to try this approach in that language.

[1] https://github.com/phillc73/duckdf

Yeah, I agree sqldf is quite slow. Fair point.

As you've seen, duckdb registers an "R data frame as a virtual table." I'm not sure what they mean by "yet" either.

Of course it is possible to write an R dataframe to an on-disk duckdb table, if that's what you want to do.

There are some simple benchmarks on the bottom of the duckdf README[1]. Essentially I found for basic SQL SELECT queries, dplyr is quicker, but for much more complex queries, the duckdf/duckdb combination performs better.

If you really want speed of course, just use data.table.

[1] https://github.com/phillc73/duckdf

That's a really good point that I'd not really thought about. I'd never really considered the difference between calling just functions versus macros.

Thinking about Query.jl and DataFramesMeta.jl, and I am for sure not an expert in either, I can't specifically speak to your `head` example, but other base functions can be combined with macros. For example, see the LINQ examples from DataFramesMeta.jl[1] where `mean` is being used. Or again the LINQ style examples in Query.jl[2], where `descending` is used in the first example, or `length` later in the Grouping examples.

Is that the kind of thing you meant?

For whatever reason, with the way my brain is wired, the LINQ style of query just works for me. I have never directly used LINQ, but do have some SQL experience. In fact, I wrote some dinky little wrapper functions[3] around duckdb[4] so I could directly query R dataframes and datatables with SQL using that backend, rather than sqldf[5].

[1] https://juliadata.github.io/DataFramesMeta.jl/stable/#@linq-...

[2] https://www.queryverse.org/Query.jl/stable/linqquerycommands...

[3] https://github.com/phillc73/duckdf

[4] https://duckdb.org/

[5] https://cran.r-project.org/web/packages/sqldf/index.html

To ruin the party, deterministic UUID generation is exactly what UUID v5 is designed for. And since Ecto does not validate UUIDs against their specs, you might as well use uuid again and do:

To me this looks a lot like ecto https://github.com/elixir-ecto/ecto

Is there a significant difference?

Ecto database driver use-case

When it comes to building microservices, Go has the advantage of being easier to deploy and tighter integration with gRPC. On the other hand, Elixir will provide a more expressive layer to communicate with the database through Ecto.

May I ask why CouchDB though? Is it for the offline support?

Phoenix comes with its own database tool called Ecto[0] which is excellent, and it uses Postgres by default. If you're not intended to leverage CouchDB for offline support you should go Postgres without a second thought.

That said, I'm also curious about how to implement offline support with Phoenix in a nice and trivial way.

[0] https://github.com/elixir-ecto/ecto

The best would be to set aside at least 40 minutes of study a day. Being 20 minutes focused on the core of the language, solving problems and a website that can help you a lot and exercism. Another 20 minutes some of the core frameworks like: Phoenix, Ecto, Enum

This is a testiment to the value and productivity of Phoenix, but the resulting code is just basic CRUD. The views are tied 1:1 with their database-backed Ecto schemas. One thing to note is that Phoenix generates DDD-style contexts. This is unlike Rails, which would produce a typical ActiveRecord sprawl: bloated models directly being accessed and lazily queried across the entire application.

Ecto uses prewalk to count the number of interpolations within a given expression.

I've used my share of data access libraries and patterns (e.g. hibernate, activerecord, ecto, ...). The only time I've been happy is when I use raw SQL for non-dynamic SQL and a lightweight query builder for everything else.

I feel like I always run into some thing that at best isn't intuitive to express/read and at worse, cannot be expressed. If I remember correctly, when I was learning Elixir/Ecto, https://github.com/elixir-ecto/ecto/issues/1616 issue and the lack of lateral join support caused me issues.

Want to create a user?

"insert into users (id, name, status) values ($1, $2, $3)"

Our query builder takes pretty raw SQL fragments:

    q = Query.new()