Closed kipcole9 closed 5 years ago
Thanks @kipcole9! Note that Mix.Ecto was private, which is why we didn't list this change in the CHANGELOG.
Thanks José. May I assume Ecto.Migrator.migrations_path/1
is public? I see nothing in the module to suggest otherwise and being consistent about where to generate migrations for libs is very helpful.
I try to use only public API's but seems I regularly step over the line unknowingly. I have interpreted an @doc
on a def
function as public - is that the wrong assumption?
Oh, i see. If you have @moduledoc false
in a module, then all functions in that module are private, regardless of @doc
. If in doubt, you can consult the online docs. Ecto.Migrator.migrations_path
is pubic though :+1:.
How should a library find the migrations_path for Ecto 2.x and 3.x?
The suggested Ecto.Migrator.migration_path should work on both. --
José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Director of R&D
Doesn't work for me (in ecto 2.2)
Ah, you are correct, sorry.
i think you can check the Ecto version or if use code.ensure_loaded? and function_exported? to see if the migrator function exists accordingly. --
José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Director of R&D
Thanks @josevalim.
Example of resolving this in another library (as pointed out on Slack): https://github.com/kipcole9/money/commit/c2766dece7f241f25b86999876d756d7b7d7a4be
Changelog update for backward incompatible API change
The function
migrations_path/1
has moved fromMix.Ecto
toEcto.Migrator
. This is understandable sinceecto 3
shouldn't have database knowledge as that's moved toecto_sql
.Suggested update to the changelog
Backwards incompatible changes
Ecto.migrations_path/1
has been removed from theMix.Ecto
module and added to theEcto.Migrator
module in theecto_sql
package.