Difference between "data" and "changes" fields in Ecto.Changeset

Yevhenii Kurtov — Thu, 07 May 2020 16:03:50 +0000

Have you ever been confused about all the different fields in the Ecto Changeset structure? Today we gonna take a look at how two of them - data and changes complement each other when building user interfaces.

I believe that a gradual and iterative explanation is the best approach to learn new material, so we will be using tests to guide our implementation.

Problem: Hide or display form element depending on user input

Setting the scene

Let’s consider an example of a Feedback entity that has a required property message and optional sender_email property. If a user doesn’t want to receive any followup on his message then email input shouldn’t be shown.
After a page is loaded this is easily achievable with JS but what about the initial page state, just after it was rendered?

On a markup level hiding email block boils down to answering a question whether a class that sets a visibility property should be added to an enclosing tag or not.

With the following schema:

schema "feedbacks" do
    field :message, :string
    field :sender_email, :string
    field :permission_to_contact, :boolean, virtual: true
  end

that decision can be made based on a value of permission_to_contact property.

To help us make the right choice Ecto.Changeset struct exposes two fields: data and changes.
data field represents original values and covers initial page load before any changes introduced by a user were made, while the changes field comes into play on subsequent renders. It represents changes made by a user and permitted during a validation phase.

Using this two we can cover the next scenarios :

Initial page load. Field is displayed based on a default contact settings ( “Yes” in our example)
User selected “No” and form should be re-rendered
User selected “Yes” and form should be re-rendered

Implementation

Setup

Add a view helper invocation that will control sender email block visibility

<div class="<%= hide_if_followup_denied(@changeset) %>">
  Email:
  <%= text_input f, :sender_email %>
</div>

Step 1: Initial page load

Test:

describe "hide_if_followup_denied/1" do
    test "on initial submission (default is that user agrees to be contacted)" do
      changeset = Ecto.Changeset.change(%Feedback{permission_to_contact: true})
      assert FeedbackView.hide_if_followup_denied(changeset) == ""
    end
  end

Implementation:

  def hide_if_followup_denied(_changeset) do
    ""
  end

Please notice, that we opted out to set default value on schema instead of a view.

field :permission_to_contact, :boolean, virtual: true, default: true

Step 2: Consecutive page render when field should be shown

This scenario covers a situation when a form has to be re-rendered with a visible field. For example, a user agreed to be contacted but provided an invalid email.

Test:

    test "on page re-render when user agrees to be contacted" do
      changeset = Ecto.Changeset.cast(%Feedback{}, %{"permission_to_contact" => "true"}, [:permission_to_contact])
      assert FeedbackView.hide_if_followup_denied
(changeset) == ""
    end

Implementation:
… we don’t have to do anything as our code already satisfies all requirements at hand:)
Just following a classical Larry Wall’s advice to develop a bit of a (good) laziness here.

Step 3: Consecutive page render when field shouldn’t be shown

Now we are going to cover a situation when a user doesn’t want to be contacted back but still wants to provide feedback and occasionally submitted a form before entering a message. Hence form has to be rendered again but email field should not be shown.

Test:

    test "on page re-render when user do not want to be contacted" do
      changeset = Ecto.Changeset.cast(%Feedback{}, %{"permission_to_contact" => "false"}, [:permission_to_contact])
      assert FeedbackView.hide_if_followup_denied(changeset) == " hidden"
    end

Final Implementation:

def hide_if_followup_denied(changeset) do
  hide_on_inital_render = changeset.data.permission_to_contact == nil && changeset.changes[:permission_to_contact] == nil
  hide_after_rerender = changeset.changes[:permission_to_contact] == false

  if hide_on_inital_render || hide_after_rerender do
    " hidden"
  else
    ""
  end
end

Closing thoughts

In this short example, we went through an exercise to see how data and changes fields of Ecto Changeset struct complements each other and enable developers to build clean UI logic.
Also, I hope that the decision to put a default value in schema made you skeptical for a moment.

We could definitely do it in a view itself, but I would argue that keeping it in schema which can be then converted to “view only” schema as described in the “Data Mapping and Validation Chapter” in “The Little Ecto Cookbook” is more beneficial in a sense that it keeps hidden_if_followup_denied responsibilities as slim as possible.

Links

https://hexdocs.pm/ecto/Ecto.Changeset.html#module-the-ecto-changeset-struct - Changeset structure

Manipulating INTERVALs in Ecto fragments

Yevhenii Kurtov — Wed, 08 Apr 2020 15:16:12 +0000

Parametarizing INTERVAL units

If you ever had to come across a task of selecting entries for last N hours/days/month you're probably already familiar with ERROR 22007 (invalid_datetime_format) invalid input syntax for type interval coming right your way from PostgreSQL.

Let's work it out on an example of selecting all emails from users that signed up during the last day or month.

A rough translation of such SQL query to Ecto can look like this

period = "day"

Repo.all(
  from(u in "users",
    select: {u.email, u.inserted_at},,
    where: u.signup_date > fragment("CURRENT_DATE - INTERVAL '1 ?'", ^period)
  )
)

As far as I'm acknowledged the reason for invalid_datetime_format error to happen is that parameter substitution is not allowed in string literals. Instead, we can rewrite the query to use a very neat trick of string concatenation to combine interval parts into a single string

period = "day"

Repo.all(
  from(u in "users",
    select: {u.email, u.inserted_at},,
    where: u.signup_date > fragment("CURRENT_DATE - ('1 ' || ?)::interval", ^period)
  )
)

voila

[
  {"text@exampe.com", ~N[2020-04-08 09:31:02.000000]},
  {"test2@example.com", ~N[2020-04-08 09:34:42.000000]}
]

Parametarizing number of INTERVAL units

Now, let's imagine that we want to parameterize the number of intervals - go from "last day/month" to "last N days/months".

Again, we know that it's impossible to do fragment("CURRENT_DATE - INTERVAL '? ?'", ^amount, ^period). Why not circumvent this limitation with multiplication?

amount = 3
period = "day"

Repo.all(
  from(u in "users",
    select: {u.email, u.inserted_at},
    where: u.signup_date > fragment("CURRENT_DATE - ('1 ' || ?)::interval * ?", ^period, ^amount)
  )
)

which gives us

[
  {"test3@example.com", ~N[2020-04-06 12:07:20.000000]},
  {"text@exampe.com", ~N[2020-04-08 09:31:02.000000]},
  {"test2@example.com", ~N[2020-04-08 09:34:42.000000]}
]

And that's how good old basic operations can save a day ;)

Kudos to peeps at #posgresql @ Freenode for explaining how to overcome those problems.

DEV Community: Yevhenii Kurtov

Difference between "data" and "changes" fields in Ecto.Changeset

Problem: Hide or display form element depending on user input

Setting the scene

Implementation

Setup

Step 1: Initial page load

Step 2: Consecutive page render when field should be shown

Step 3: Consecutive page render when field shouldn’t be shown

Closing thoughts

Links

Manipulating INTERVALs in Ecto fragments

Parametarizing INTERVAL units

Parametarizing number of INTERVAL units