Phoenix v1.3.0-rc.0 released


Congratulations to Chris, the @Phoenix-Core-Team and everyone who has worked on it - awesome release :023:

I’m pleased to see this, looks much better Imo :slight_smile:


Thanks for information!


Try this. Create a new project with mix new hello and then change the mix.exs file to do the following:

defp deps do
   [{:phoenix, "~> 1.3.0-rc"},]

Can Hex fetch Phoenix? If it cannot, it is an issue with your Hex installation. Or it cannot find Phoenix or it cannot update the registry metadata. If so, try deleting any *.ets or *.ets.gz files in ~/.hex.


What was the motivation behind changing directory structure? The one with main modules nested in lib and other modules in the same named folders seemed really reasonable - it was quite natural split between high level API and implementation details. It is also convention used in every library in the language and I believe would make it easier to eventually split app into separate OTP apps as needed.

Besides that - great direction! I really like how Phoenix emphasizes its use case and does not want to be all-in package - it always bothered me with Rails.


Thank you!
It seems to be caused by the hex mirror. After removing mirror_url in hex.config, everything goes well.


Thanks @chrismccord for this! It’s awesome. When I digged into Phoenix few months ago I saw it uses some parts of DDD eg. isolated repo to orchestrate the models, but now it’s all right. Bounded Contexts are another needed level of abstraction, so controller doesn’t look like “I’m the boss and I force repo to do anything for me”, but he deals with BCs. Also changing the structure is very nice.

Does the live reload now apply for /lib/myapp/web/*? I guess it is. Also I like generators using phx and your effort that we should think more about the code and how we gonna use it and less about generating CRUDs and wondering how to modify them :slight_smile:


To clarify - ecto repo is not a repository pattern. It differs in some key areas, most notably repository pattern calls for a repo per entity you’re going to query - ecto has just one repo that is used to explicitly represent the database in the code - one for all entities.

Neither phoenix’s contexts are bounded contexts per DDD on their own - you can use them as such, but there’s nothing that requires it. I’m sure it was an inspiration, but I’m also pretty sure the phoenix team does not want to enforce DDD on everybody.


Yeah, but I don’t follow DDD as it is. I just like that’s what’s most important and usable is in Phoenix as it should be. Using BCs is concise, clear and will make controllers way more thin :slight_smile:

Also action_fallback is great here and using with clause.


I too am used to the convention where my_context.ex and my_context/ are in the same directory. The module names MyContext and MyContext.MySchema are also consistent with the former structure.


Is there anyway to prevent ecto? Earlier was --no-ecto.



yes, same flag, mix my_app --no-ecto


Just as a clarification, two questions:

I. Is it ok to use the context itself as a schema? For instance, with:

mix phx.gen.html Accounts User users email:string:unique

If I wanted Accounts and Account Users (multiple Users per Account), would I then run:

mix phx.gen.html Accounts Account accounts ....

II. With many to many associations (Tags and Posts for example), I presume it’s up to the developer to decide on one context (either Tags.Post or Posts.Tag, but not both)


Thank you @chrismccord @wojtekmach @josevalim and everyone else for making this happen! I really can’t wait to move our applications to the new structure and then from there to umbrella when people agree with the direction or they get to a bigger size :slight_smile:


Hello! I can’t understand proper web/* scoping now. Before I was able to do:

mix phoenix.gen.model User users ...
mix phoenix.gen.html Admin.User users --no-model

What should I use now?


Congratulations on the release! I love the new directory structure :slight_smile:


I wonder if this will be the most liked thread this year :003:


I have opened issues to support the --no-schema and --no-context options. If folks would like to contribute, this is a great opportunity. :slight_smile:


One more changelog entry that didn’t make it into the initial changelog from some of my colleagues :grinning::

  • [Digester] Add mix phx.digest.clean to remove old versions of compiled assets


Is this nesting going to be a recommended practice Elixir-wide (so lib/ecto/ecto.ex instead of the current lib/ecto.ex) or is this a Phoenix-only thing?


Hooray! I’m a huge fan of the lib/web consolidation and how it lets standard approaches to breaking up an app into an umbrella app work smoothly!