FYI, for now, I'll try doing *ecto.dump* on the original server and then transfer the generated .sql file to the new server and do *ecto.load* on that one. That's probably the best way I can think of to do it.
On Wednesday, August 10, 2016 at 1:49:09 PM UTC-7, David Escobar wrote: > > I did try *ecto.dump *followed by *ecto.load* but that did not work when > bringing up the database on a new server. The .sql file it generated did > not contain any schema information because the database had just been > created with *ecto.create*. > > Is this possible to do with Ecto? If not, what is the community's best > practice way of doing this (besides writing custom SQL scripts)? On > longer-running projects, there may be a lot of migrations (including data > migrations) and running all of them historically (with *ecto.migrate*) > is, at best, time-consuming and at worst, error prone. > > Thanks. > > > > On Wednesday, August 10, 2016 at 1:33:58 PM UTC-7, Michał Muskała wrote: >> >> >> > On 10 Aug 2016, at 22:27, David Escobar <davidesc...@gmail.com> wrote: >> > >> > >> > I've looked through the various options and cannot seem to find the >> Rails equivalent of 'rake db:schema:load'. Am I missing the right way to >> invoke this in Ecto, or did this get pushed out to a future version? >> > >> >> You’re looking for ecto.load, and the complementary ecto.dump tasks. They >> save the database structure in the format native to the database - there’s >> no special DSL like rails schema has. >> >> Michał. >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/ce82631f-955c-400c-bd9e-86374ef2daf0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
