Polymorphic relations and transient data

Question:

I have a architecture question about dealing with transient data when creating Polymorphic relational records.

I’m trying to figure out the best scenario for dealing with my current example based the ability to address idempotency, orphaned data (‘garbage management’) and performance.

Below I outline what I’m working with and I would like to know how other people have solved this problem.

Thank you

  • Josh Chernoff.

Example

I have two models.

  • Post
  • Image

Post and Image relate via an images_posts join table and via ecto’s

many_to_many :images, MyApp.Image, join_through: "images_posts"`

Current Dependancies:

  • Arc (image uploader with using ex_aws)

Scenarios

  • Using a Single http POST request to create a new Post record I upload all the form data for the Post along with the all the Image data. The controller action handles creating the Post first then respectively all the images in one request.
    Con: Validations will cause a user to re upload images
    Pro: The logic is procedural and easy to conceptualize

  • Using multiple http POST requests I create images one by one passing back ids that the Post form will use laster to build the relation.
    Con: Image data can become orphaned, more logic is needed to build the relations and clean up transient data.
    Pro: Form validation has less of a performance impact.

  • (‘conceptual idea’) Using elixir’s processes make a temp place to store the Image records and upload each Image one by one then later make reference to the processes when creating the Post.
    I have to admit I have no idea what this looks like and it was only mentioned to me in passing by someone as an option. The idea is that you treat the Image data as transient data as much as possible and only create the Image record when creating the Post is successful removing the need to deal with clean up ect…

2 Likes

It’s definitely good to support consistency in entities meaning - if post created it existing, same with image entity. You don’t want to create post which can’t be rendered, or image that have no meaning, because it belongs to nothing.

I didn’t implement such in elixir yet, but how about to introduce a draft state to post? So then you hit a “create new” every time a blank post with draft state is created and you have a post id.

In such case post entity preserves the meaning, and user experience is better, he can leave post with images for a better time, and no orphans. And with elixir separation of schema and changeset concerns beats wonderful here (use draft_changeset in save draft action and publication_changeset in publish action).

About third scenario (‘conceptual idea’). I think you don’t need the second point of state here, you already have a database. Don’t store them in “temp place”, let database be this place. Just separate a concern of “temp”, like introducing TempImage model, and remove orphaned images on reached condition (time expired, user uploaded too many images).

2 Likes