Hi Alchemists, we’re investigating whether the migration of our (simple) Rails API to Phoenix is a viable step for us. As we can’t migrate the Rails database schema to ecto, I’m interested in how to use Phoenix just with raw SQL queries. Is it recommended to drop ecto and setup the database connec…

This Stackoverflow thread might be of interested and quite simple.

@railsmechanic , you will loose a lot of cool things without ecto. Check this video: [RailsConf 2016 - ActiveRecord vs. Ecto: A Tale of Two ORMs by Brad Urani]

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 set…

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 matt…

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 …

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 necessa…