Phoenix with just raw SQL

This Stackoverflow thread might be of interested and quite simple.

@railsmechanic, you will loose a lot of cool things without ecto.
Check this video:

If you opt for stored procedures as opposed to using raw queries you will actually gain a lot of flexibility compared to using ORM.

I know, but a complete migration to ecto is not possible at the moment.

It’s also worth noting that Phoenix has nothing to do with this at all, it is merely a web framework.

What prevents you from migrating the rails schema to ecto?

I know that Phoenix is “just” a web framework, but I don’t want to reinvent the wheel by writing my own database connection pool and stuff etc. Before doing this, I just wanted to know whether a default Phoenix respectively ecto installation is able to execute raw SQL queries without the need to setup models/schemas.

The reason for all this is, as we cannot migrate the rails schema to ecto at the moment, because our customer is using the underlying database from other systems which don’t belong to us. Otherwise we’ve already migrated the service.

As someone who hasn’t really used Rails / ORM before, I don’t understand the benefits. Whenever I see the convoluted Ecto code, I just think “isn’t it easier to just write the SQL?”. I don’t buy the portability argument - if you want to change from mySQL to postgres, you’re in for some pain, no matter the abstraction.

I’m admittedly naive to the pros of this, given the lack of experience with the tools.

Curious to hear how one would utilise raw SQL.

M

You can look at the drivers: GitHub - elixir-ecto/postgrex: PostgreSQL driver for Elixir · GitHub and
GitHub - xerions/mariaex: Pure Elixir database driver for MariaDB / MySQL · GitHub - they are built on top of db_connection
so they have pooling, transactions support, etc. For postgres you could
also look at GitHub - robconery/moebius: A functional query tool for Elixir · GitHub for postgres that is
closer to SQL.

That said, you don’t need to change anything in your database to be able to
use ecto. You can simply define your schema modules and skip migrations.
I’ve heard couple stories of ecto working fine with a rails database.

I agree that the argument of changing the database is completely
nonsensical. I have yet to see a system that does not use any
database-specific queries.

I see the strength of ecto in different areas - changesets are extremely
powerful and convenient way to work with data in general, not necessarily
database-originating data. Custom type definitions and automatic casting
make it a breeze to build systems. There are also some additional features
around handling associations, properly parametrizing queries, etc. Making
queries composeable is also a powerful idea that simplifies code
tremendously.

While I could definitely live without queries and write raw SQL,
abstractions such as changesets, multi and types are definitely a huge
improvement.

Many thanks, moebius looks surprising…