Hello one and all, I am trying to create a full stack app with react and phoenix from an article that uses phoenix 1.3 while I’m using the latest version 1.5.7. in the article, the models db access is used and version 1.5.7 no longer uses the models so my app gives me the following error when I send a get request from postman0
function Repo.all/1 is undefined (module Repo is not available)
The controller file
defmodule PhxReactList7Web.BlogsController do
use PhxReactList7Web, :controller
alias PhxReactList7.Blogs
def index(conn, _params) do
blogs = Repo.all(Blogs)
render conn, "index.json", blogs: blogs
end
end
the repo file
defmodule PhxReactList7.Repo do
use Ecto.Repo,
otp_app: :phx_react_list_7,
adapter: Ecto.Adapters.Postgres
end
the blogs file
defmodule PhxReactList7.Blogs do
import Ecto.Query, warn: false
end
In the docs, Repo.fun/arity needs to be considered as MyApp.Repo.fun. So in your example, I would suggest adding alias PhxReactList7.Repo in your controller and you should be good to go.
defmodule PhxReactList7Web.BlogsController do
use PhxReactList7Web, :controller
alias PhxReactList7.Blogs
alias PhxReactList7.Repo
def index(conn, _params) do
blogs = Repo.all(Blogs)
render conn, "index.json", blogs: blogs
end
end
and now I get the error:
protocol Ecto.Queryable not implemented for PhxReactList7.Blogs of type Atom, the given module does not provide a schema. This protocol is implemented for the following type(s): Atom, BitString, Ecto.Query, Ecto.SubQuery, Tuple
I guess my main problem is that I am totally confused where the schema and the database tables are defined and used inside the application as the steps described in the article do now correspond to the current version.
I have read both the controllers guides and the ecto guides but I still have not made the connection between the dots metaphorically.
I did the migration step and that worked, I then added a few records to the database so I’m good there.
Database tables are defined in the migrations. You didn’t create a schema in your .Blogs module
Ecto treats schemas separately from the database and does not autopopulate it for you. You can have more than one schema for any given database table, you can use that to enforce contextual boundaries on database columns access (context A needs to only see these columns and context B needs to only see these other columns)
I did create a schema, the file name is blogs.ex under the blogs directory under the app directory
the file looks like this:
defmodule PhxReactList7.Blog do
use Ecto.Schema
import Ecto.Changeset
schema "blogs" do
field :title, :string
field :subtitle, :string
field :image, :string
field :link, :string
field :author, :string
timestamps()
end
@doc false
def changeset(blogs, attrs) do
blogs
|> cast(attrs, [:title, :subtitle, :image, :link, :author])
|> validate_required([:title, :subtitle, :image, :link, :author])
end
end
I followed the Ecto guides in creating the schema file, but I may have the object names wrong…
I figured as much. I did just as are suggesting and created the friends mix app as shown in the Ecto guides but that demo does not go far enough as it does not have a front end section to the example that uses the created schema/tables context
I will start all over again by reading about context and other things and also I will put the project in github so I don’t have to cut and paste like I’m doing now…
the Blogs, Blogs.blog, blogs and other bloggie issues did not work for me… again because of the 1.3 to 1.5 incompatibility issue and there does not seem to be any docs that amplify or describe the way to go from one to the other…
Oh boy have I been into google, but sometimes friends do not understand what you are trying to ask or the questions do not make any sense to your friend, so the answers do not help.
No prob, will continue to google, and to bing it with edge as well.
Thanks again, will read the medium article since I also am a subscriber…
just to be clear, you need to pass the PhxReactList7.Blog module to the repo function. Currently you are passing the PhxReactList7.Blogs module to the repo function.
I don’t love this (the default ecto) naming scheme, I do something completely different myself, where I break out into submodules for contexts, schemas, changesets, queries
I did that a while back but the torrent of Ecto error messages just got to me, so I took a day off and went back started with the index function on the controller with its main Repo error message and started posting here after failing to get any answers form my friend google that made any sense. I removed all the code I had added to the controller for the other CRUD functionality to make things simple and the posting question smaller and easier to understand and explain.
I also was able to get my react webpages to connect to the controller without any problems until I started hooking up the db functionality, so at least I can hook a web page to the app, that’s something I think.
yeah, I am having a HUGE problem with the naming/context conventions.i’m also having a problem with breaking changes between different versions for something that can have a big impact on a company’s software selection for its product cycle.
I used to teach SQL, and one of my lectures dealt with names and naming conventions. People don’t realize that this is a very big problem in large applications where you can have 100++ tables with multiple schemas and multiple views where the naming can be a real pain the derriere or somewhere near there… LoL…
I did a demo using the phx.gen.context and that went well, however, I’m trying to understand the complete process from the bottom up without the sugar coated wrapper generated by the phx.gen.* helper functions.
I also used the phx.gen.schema and the phx.gen.html, but again I’m trying to understand the system from the ground up…
there is some trickiness (two or three ways around it) you have to be aware of in order to properly use changesets that are not in the same module as the schema. I honestly don’t really recommend this until you’ve done at least one full project using the Ecto Default. The HyperHypeBeast is optimized for teams of more than about 2-4. Also note that this is just an architecture plan, it still needs to be approved by ben and none of the refactoring has been executed yet (as there are no tests yet, lol)
well, i’m a bit away form implementing anything like it. I did follow the schemas and found that the module names are singular ie room, versus the schema names which are plural ie: rooms… I need to get a handle on that… which is what @kokolegorille point out to me… I did find some issues with that as well.