moja VS ecto

I want sum types.

I want a statically-typed way of constructing composable queries that follow SQL rather than reinvent a different thing. It doesn't have to be the same syntax but it has to be the same structuring.

I started writing one[0] and stopped before doing all the boilerplate code generation, having moved on from the JVM ecosystem for the time being. One thing it does is treat most things like sets so we don't end up with N+1 queries. Another trick it uses is collapsing constant expressions via an expression evaluation library[1].

[0] https://github.com/karmakaze/safeql

[1] https://github.com/karmakaze/moja

Over the years, I've written many apps and utilities for myself or others (that didn't end up get used). These are the interesting ones I remember. Many not quite complete/usable. Other than hackerer.news none of them are 'up' and running. Some have and others haven't been published as opensource.

- https://hackerer.news HN viewer (source[0]): I use daily so I can see today's top stories in reverse chronological order with mainstream topics sorted to the bottom.

- qwickly[1] keyboard layout: I use all the time as an easier to learn and more comfortable to type than Colemak/Tarmak

- safeql[2]: Java type-safe SQL expression composer that reduces constant expressions and eliminates N+1 queries loading associations by always operating on set relation or array of models.

- moja[3]: Composable computation pipelines for Java: Async, Lazy, Option, Try, Result, Multi (List), Stated, Reader, Logger, Writer.

- gitgrep.com[4] Opensource SaaS version of etsy/houndd (now called hound-search).

- statuspages.me: Status page aggregator with dynamic javascript for scraping each source using selector expressions.

- movies to watch aggregator: with links to sources to watch. It was hard then to get 3rd party deep links into streaming sites so included some torrent links. Got a DMCA phone call, so took it down. Combined thumbnails, summaries, actors(?), imdb ratings, links.

- java2cpp: Translate a moderately sized java app with test suite to c++, not 100% required final manual fixups.

- swift2java (or maybe it was java2swift, it's fuzzy now): translate Swift to Java obviously, using ANTLR4. Not 100% required final manual fixups.

- gui2log: to make an ASCII rendition of on-screen GUI widgets into an application log file when form submitted, so users couldn't complain that they saw X, but got Y.

- some basic stats/ML algorithms: k-nearest neighbour, RNN back-propagation, etc?

- Java in-memory DB: Small SQL-like memory tables with indexing/searching.

- wwwsqldesigner: This exists as opensource and I extended it to infer foreign key relationships based on naming conventions used in a MySQL schema. It was great for zooming around a large ERD.

- tracelog: combination of microservices parent/child span logging and generated high level events shown as a sequence diagram. Integrated with Loggly for full/verbose logs of selected high-level events.

- pcl2bmp downscaler: Reduce high resolution HP LaserJet (PCL5) printed to file to lower resolution bitmap pages for screen display (before retina DPI was common). It aimed to shrink same-color areas and preserve black/white transitions while reducing.

[0] https://gitlab.com/karmakaze/hackerer-news

[1] https://github.com/qwickly-org/Qwickly

[2] https://github.com/karmakaze/safeql

[3] https://github.com/karmakaze/moja

[4] https://github.com/gitgrep-com/gitgrep

Sure, SafeQL[0] SQL library. It's been sitting in a close but not enough to promote state for a while. The main thing I wanted was to have generation of the bindings to existing DB schema. I also want to combine using Moja[1] datatypes for uniform handling of single/multi, normal/async, and errors.

[0] https://github.com/karmakaze/safeql

[1] https://github.com/karmakaze/moja

I made a similar thing for Java moja Options as needed other projects. It sort-of works but it's not great.

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()