How Should I Migrate this?

[AdamBrodzinski]

I'm going to be migrating most of my app over to Elixir/Rethink next week and I had a few questions on Elixir patterns in general as well as Ecto's changeset. If you happen to have a couple of mins I would greatly appreciate your advice!

Where would I place this code in an Elixir app? It's coming out of a JS class as a static method so I was thinking of just making a MyApp.Reminder module with some functions that produce side effects. So far this seems like the best idea to me and a test would just run against the DB to check the result.

However, then this made me wonder if I should be using Ecto's changesets? This is mainly what i'm stuck on. I only have about 5 of these functions so it initially seemed like overkill to have a updateReminderStatus that called a mutateReminderStatus function.

This wouldn't be accessed from the API endpoint directly (something a scheduler would indirectly run it) so I didn't think the 'controller' was the place for it. Ecto 2 seems to be removing the 'model' so I didn't think I should hang it off of that.

// updates the status of the reminder to 'active:false' if the reminder
// will not repeat. Adds the scheduledAt date to the `sentLog` array
//
// doc - {Object} Rethink reminder document
// returns {Number} of documents updated
//
function updateReminderStatus(doc) {
  let info;
  const lastTimestamp = doc.scheduledAt;

  info = Reminders.get(doc.id)
  .update({
    active: (doc.recurFrequency) ? true : false,
    updatedAt: new Date(),
    sentLog: r.row('sentLog').append(lastTimestamp),
  }).run();

  return info.replaced;
}

[AdamBrodzinski]

Also if you need a guinea pig for any Ecto 2.0 ideas let me know and i'm happy to test them in another branch (this app is heavily tested on non-critical). I wasn't sure if you were still planning on supporting this after reading the Ecto mailing list thread.

Speaking of that thread, if my use cases help for feedback, having just changesets and a schema solve my uses cases. I was briefly considering creating one before I realized I could still use it without a specific db.

Before using Elixir i've been using an ORM-less setup with Mongo and Meteor and have been using SimpleSchema to check unsafe params.

Hex doesn't have any kind of a schema package so it might even be useful to extract Schema and Changesets from Ecto and call it a day (even if the package just imported Ecto directly and provided a new facade). I really wish they had them decoupled completely so there wasn't an expectation to support all of Ecto.

[hamiltop]

There are two avenues I'd like to see pursued.

1. Port existing app to RethinkDB.
2. Brand new app from the ground up.

One of the big gaps right now is migrations. I think the above two use cases will expose very different sets of issues.

I've got a pet project that I've been waiting to do that will satisfy the second case. Do you plan on having migrations (creating tables, adding indexes, etc. are all still very relevant)?

As far as long term plan with this lib, I think I'm commited to the approach I'm taking here. It will be a drop in replacement for Repo, rather than an Adapter. There's going to be a few functions that are unsupported, and I'm fine failing loudly in those cases. I think I am going to only support Ecto 2.0 though, since the callbacks were one of my pain points.

[AdamBrodzinski]

Sounds good! So my one app is existing but is written in Node (Meteor actually) so it wouldn't hit the same issues that an existing Phoenix app would. My only issue is keeping the data consistent, which seems to not be a big issue so far.

Honestly i've never used migrations except a few toy Rails apps. I've been using Mongo the last 3 years so i've manually added tables and migrations in the console as needed (and had a hosted DB). For me having support for migrations is not a big deal.... if I create a 'posts' table and need to rollback to code that doesn't use a posts table... life still goes on.