How to run a SELECT WHERE column IN (...) query?

I tried using the Ecto.Query API, like this:

  query = from chat_user_rooms in "chat_user_rooms",
    join:   chat_user_notification_keys in "chat_user_notification_keys",
    where:  chat_user_notification_keys.user_id == chat_user_rooms.user_id,
    join:   users in "users",
    where:  users.id == chat_user_rooms.user_id,
    join:   chat_rooms in "chat_rooms",
    where:  chat_rooms.id == chat_user_rooms.room_id,
    where:  chat_rooms.id_ref == type(^room_id, :uuid),
    where:  users.slug in ^user_slugs_who_are_present,
    select: chat_user_notification_keys.key

This fails because room_id is a string, but the database type is a UUID. The above fails with:

** (UndefinedFunctionError) function :uuid.cast/1 is undefined (module :uuid is not available)
             :uuid.cast("afe13f89-7819-43d9-9bb8-b4ba38a2ddac")

If I remove the type cast, then Postgrex complains with:

** (ArgumentError) Postgrex expected a binary of 16 bytes, got "afe13f89-7819-43d9-9bb8-b4ba38a2ddac". Please make sure the value you are passing matches the definition in your table or in your query or convert the value accordingly.

Note that the above query is not even the same query I wrote originally. I used NOT IN, but this query is IN. I have to find how to do a NOT IN now.

Thanks!

not users.slug in ^user_slugs_who_are_present, the not is a unary function, the inis a binary function, thus the precedence is likenot(users.slug in ^user_slugs_who_are_present)`.

I think a future-elixir version is going to allow not in as a binary function though, I think…

Strings are not UUID’s. Something like "afe13f89-7819-43d9-9bb8-b4ba38a2ddac" is not a UUID but is a string. A UUID is 16 bytes of binary. The "afe13f89-7819-43d9-9bb8-b4ba38a2ddac" is a common human-readable representation but you should never ever ever pass around UUID’s in the human readable representation and should keep them as what they are, 16-byte binaries (in my humble opinion ^.^). However yes, you need to cast it with I think it is Ecto.UUID.cast, not :uuid.

Thanks @OvermindDL1. The UUIDs are coming straight from the UI layer. I kept them as strings, because that makes it easy to inspect the value from anywhere in the stack.

I finally found a solution to my problem by reusing the ANY operator. My original SQL query is now:

-- as before
  AND NOT users.slug = ANY ($2::text[])

This works and satisfies me.

Thanks!

You need to dump the string UUID first to a binary like this:

{:ok, bin} = Ecto.UUID.load(room_id)

Now you can use the binary UUID directly in your query like this:

where: chat_rooms.id_ref == ^bin

Note that if you use an Ecto schema, you don’t need to do all this manual casting and dumping.

@zambai, {:ok, bin} = Ecto.UUID.load(room_id) is casting. I still have to do it somewhere. The schema isn’t free: the cost has to be paid somewhere.

I’m not sure if I understand what your meaning. Are you worried about the performance overhead of Ecto?

No, you said “you don’t need to do all this manual casting and dumping”. I only pointed out that it had to be done somewhere, either at the point of the query, or before, in the controller layer. HTTP only speaks strings. Casting will merely be done somewhere else.

What @zambal is saying is that if you had a schema, YOUR code wouldn’t need to worry about casting at all, Ecto would know what type it should be and will cast for you.