Filtering by UUID using 'like' operators in Elide 6

[Asky-GH]

Hi! Can we use 'like' operators (in/ini) when filtering by the id of type UUID?

[aklish]

You should be able to use in/ini on UUID types. You should also be able to use infix, prefix, and postfix. For 'like' operators, the requirement is that there exists a Serde to map the field type to a String. Let me know if something isn't working as expected.

[Asky-GH]

Should my Serde look like this?

@ElideTypeConverter(type = UUID.class, name = "UUID")
public class UUIDSerde implements Serde<String, UUID> {
    
    @Override
    public UUID deserialize(String value) {
        return UUID.fromString(value);
    }

    @Override
    public String serialize(UUID value) {
        return value.toString();
    }
}

[aklish]

Elide already has built in support for UUID so you shouldn’t have to define a Serde in this instance.

…

On Mon, Jan 31, 2022 at 10:59 PM Asky-GH ***@***.***> wrote: Should my Serde look like this? @ElideTypeConverter(type = UUID.class, name = "UUID")public class UUIDSerde implements Serde<String, UUID> { @OverRide public UUID deserialize(String value) { return UUID.fromString(value); } @OverRide public String serialize(UUID value) { return value.toString(); } } — Reply to this email directly, view it on GitHub <#2529 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVH6QNOSMLFLCZOSHF5R4LUY5SEFANCNFSM5NEPKUZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[Asky-GH]

But what do you mean by this "For 'like' operators, the requirement is that there exists a Serde to map the field type to a String."

[aklish]

I meant that if your model has a numeric type (Integer), you can't use 'like' operators (prefix, infix, postfix). To leverage those filter predicates your model field must be a String or a field that is mapped to a String as a Serde. For your use case, you can just represent your UUID using the native UUID class in your model, and you should be able to leverage all the operators. Because Elide already has native support for UUID, you don't need to build a Serde in this case (internally it coerces it to a String if it needs to).

[Asky-GH]

Are you talking about ToUUIDConverter?

Maybe I'm doing something wrong but currently, when I perform a request like so, for example, /books?filter[books]=id=='*9f030f635598*' (my Book entity has an id of type UUID here) I get such a mistake java.lang.IllegalArgumentException: Invalid UUID string: *9f030f635598*.

The exception is thrown on this line of ToUUIDConverter

return (T) UUID.fromString(String.valueOf(value));

[aklish]

I dug into this and have two thoughts:

1. So Elide (RSQLFilterDialect) does validation on the values of a filter predicate to make sure they are of the correct underlying type. This probably ought to happen after Elide understands the operator (eq, in, prefix, gt, etc) because for some operators, it doesn't make sense to do type coercion. For example, a value of a like operator (prefix) cannot be reasonably coerced to the underlying type because the prefix may not be a legal type. We could skip coercion in this case (for these operators), and let the filter proceed. That is one option.
2. For your use case, in and ini should work fine with UUIDs, but prefix, postfix and infix will not (anything requiring an asterisk). Given that UUIDs are random, is there a reason to want to use a 'like' operator on it? Is this for typeahead or something along those lines?

[Asky-GH]

In our system, we show users the first 8 characters of an id (something similar to git's commits). Along with utilizing it for some personal reasons they use it in a quick search. We ended up creating a dedicated view with an additional id field with a string representation of the original id (UUID). Maybe @ComputedAttribute could be another option.

[aklish]

I'm thinking about moving the validation logic for predicates to allow this. One unfortunate problem though is that there are really three different representations for a UUID - the client representation (String with hyphens), the in memory representation (a UUID object), and the database representation (String without hyphens). Elide does filtering potentially both in the database and in-memory. When doing 'like' style queries, the client filter will include hyphens which will work fine in-memory but not in the database. To leverage 'like' predicates, you would also have to override the database serialization of the UUID to include hyphens. Let me know if this is still useful.

[Asky-GH]

It looks like the use case that I've mentioned is pretty rare. Based on your answer, in my opinion, it's not worth it. Furthermore, it's not a blocker since at least one alternative solution exists.