Violation of changeset design principals? about whatwasit

[joshgoebel]

I feel like the right injection point might be a new Repo module or wrapper function around the repo itself vs the changeset...

changeset = Model.changeset(data)
VersioningRepo.insert!(changeset)

or

changeset = Model.changeset(data)
TrackChanges.insert!(changeset, MyApp.Repo)

Just some thoughts.

[smpallen99]

My original attempt was to override the insert and delete actions on the repo. José’s feedback was to use the changeset, so that is what I did.

I don’t think there is anything stopping someone one doing at the repo level. Just don’t use the prepare_version api. The basic APIs should be available to do the inserts at the repo level.

Steve

On Jul 23, 2016, at 3:04 PM, Josh Goebel [email protected] wrote:

I feel like the right injection point might be a new Repo module or wrapper function around the repo itself vs the changeset...

changeset = Model.changeset(data)
VersioningRepo.insert!(changeset)
or

changeset = Model.changeset(data)
TrackChanges.insert!(changeset, MyApp.Repo)
Just some thoughts.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #4 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA2YpeWXMHGTptWMF8qUG-3sCUvhAgHIks5qYmXJgaJpZM4JTa52.

[joshgoebel]

I pinged him on Twitter with my question. It just seems like you're making (suggesting) a change to changeset() that entirely alters the behavior of it.

I'm very curious to see the "right" way to do this in Elixir (it's the exact reason i came to read this code in the first place), but this doesn't feel like it. And imagine we start to have a bunch of other "plugins" that do things with outside side effects (send an email, text, etc)... is the recommendation really to put them ALL inside changeset?

[joshgoebel]

Also for most systems shouldn't we really include a transaction in the examples? What about something like:

Repo.transaction fn ->
  changeset = Model.changeset(model, new_data)
  |> Model.save_prior_version!
  |> Repo.insert!
end

[smpallen99]

@yyyc514 Actually, there are no side effects in the changeset. prepare_versions uses the Changeset.prepare_changes api. It is passed an ann fun that gets called during the Repo action. If the Repo action fails, the prepare_changes function does not get called. So, there is no need for a transaction.

If you read the docs for prepare_changes you'll see that it is designed for this type of post processing.

[josevalim]

So to clarify: changesets are split in two stages. The casting, validation, preparing are first and are side-effect free. Then, once you send it to the repository, all side-effects happen. This includes inserting to the database, running prepare_changes, and setting up transactions (if prepare changes or associations are included). So I wouldn't say changesets are side-effects free but rather they split the stages with side-effects and without side-effects in two very clear steps. There is still a lot of benefit in splitting, you get to have completely sane and immutable semantics until the database comes into action. Btw, the transaction is automatically taken care of if you have associations or set prepare_changes.

[joshgoebel]

Changeset.prepare_changes Ah that is what I was somehow missing. Thank you! Now it's all so very clear. :-) Closing issue.

[joshgoebel]

@smpallen99 Sorry for the confusion. :)

[smpallen99]

Josh,

No problem. It was a good discussion. I appreciate José’s description of the two stages of a changeset.

Steve

On Jul 24, 2016, at 12:32 PM, Josh Goebel [email protected] wrote:

@smpallen99 https://github.com/smpallen99 Sorry for the confusion. :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #4 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA2YpTEX044AvKcdi-dBxIaAZtmYi8ckks5qY5OIgaJpZM4JTa52.