Hey!

Just to answer your first post bold question:

Is there some kind of guide one pitfalls, gotchas, best practices… maybe an unfinished blog article on the matter?

I’ve written a few months ago a series of articles about my own experience of migrating a Phoenix project to Ash.

Here is the link: Migration to Ash series | Blog of the (p)repair project

It covers with some details and complete code example the migration process from an Ecto Schema to an Ash Resource.

I wrote it for me, as a way to validate my comprehension of the process and differences between frameworks approaches. I also wrote it with the goal to share it with the community. Because I spent a lot of time during last spring (April and May 2024) on the Ash Discord, and I received many help from Ash developers and users .

Finally I had to switch my life project and to find a new job to get revenue (my first job as a programmer, and unfortunately it’s not in Elixir but PHP and JavaScript, but now that I start to get used of these “new” languages, I’m switching back to my (p)repair project on my free time). Well I guess, that’s out of the current topic .

Hope these articles can help new Ash adopters which would came from Phoenix !

Having done this migration on a large ERP with tons of schemas, I can advise these steps:

1. Prefix the Ash stuff you add, like MyApp.Ash.[...]. This makes it easy to namespace Ecto schemas vs Ash resources. They can coexist while you migrate. If you are depending on PubSub, you’ll need to do a little bit of cross-notification integration between the two in places where the app is using the same schema/resource in both paradigms. Personally, I found it easier in general to avoid that by just migrating an entire context at once. YMMV.

2. Implement all new features in Ash.

3. As you migrate from your old contexts, you can gradually remove your deprecated modules when they are no longer used.

4. Once all your old modules are gone, you can do a little search & replace to get rid of the .Ash. namespace if you want.

Note: Pay close attention to Zach’s advice about the migration generator. It is very worth using, just make sure you delete anything that was already done in your previous migrations.

I don’t believe that there is any particular guide for this

I’m happy to use this thread to answer questions on this regard. The most important thing to keep in mind is:

You can turn your Ecto repo into an AshPostgres.Repo and still use it with Ecto .
Ash’s generated migrations are also standard ecto migrations meaning that they should be compatible as-is. Because you already have some database structure, you may end up generating migrations and then deleting or hand-modifying the generated migrations sometimes etc.

You may also be interested in the task to bootstrap a suite of Ash resources from a postgres database:

mix ash_postgres.gen.resource MyApp.MyDomain