Questions on implementation?

[RobStallion]

Creating an issue as a place to ask questions on implementation.

Why do we have the function check_for_unique_index()? I'm guessing it is because alog cannot be used on tables that have unique index applied but the why is not obvious to me.

[Danwhy]

If a table has a unique index on a particular column, eg: email, it would mean that you cannot have two rows in the database with the same email. So when a row is updated, the row is completely replaced, meaning there will still only be one row with a particular email.

However with Alog, if we update a row it will create a new row, so there will now be two rows with the same email. If the table has a unique index, this won't be allowed and the update entry will just be rejected.

So to avoid these errors in updating, we need to make sure a table does not have a unique index applied when Alog is used.

[RobStallion]

@Danwhy why is the query in the all/0 function split into sub and query?

        sub =
          from(m in __MODULE__,
            distinct: m.entry_id,
            order_by: [desc: :updated_at],
            select: m
          )

        query = from(m in subquery(sub), where: not m.deleted, select: m)

Would we be able to do this in one query like so?

from(m in __MODULE__, distinct: m.entry_id, order_by: [desc: :updated_at], where: not m.deleted)

(I'm guessing not but I can't see any reason why. If someone can explain if I am missing something that would be 👍 )

[RobStallion]

Don't know why I didn't think of this last night 😑

I'll just check it myself by updating the query and running the tests locally.

[Danwhy]

@RobStallion If we do it all in one, the order_by isn't applied until after the results are selected, so there's no guarantee we'll get the latest one in the distinct.