Backoffice routing does not work with non-Long ids

[preslavrachev]

I was eager to try the Backoffice, but it won't work for us out of the box. The reason is, because most of our entity IDs are strings (hashes, special regular-expression patterns, etc). Thus, none of the routes would work.

I recall that when we set out to do our own version of a Quarkus Admin, we faced the same problem and agreed that using a String everywhere, and trying to convert for the different ID types at runtime is the more versatile option.

How feasible is it to accept Strings in the routing, too?

[FroMage]

So, you extend PanacheEntityBase and not PanacheEntity, in order to define custom IDs, is that it?

[simeonlin]

I would also love to see Backoffice working with PanacheEntityBase and even with a PanacheRepository setup. 😊

[FroMage]

I am willing to add support for PanacheEntityBase, but for repos, I'll take a PR ;)

[FroMage]

What sort of @Id declaration do you have, then? And how do you set them? I assume they're not @GeneratedValue?

[FroMage]

Should be fixed now.

[preslavrachev]

@FroMage Thanks, I will check out the new build. I wanted to reply earlier to your comment:

What sort of @Id declaration do you have, then? And how do you set them? I assume they're not @GeneratedValue?

Indeed, they are rarely a @GeneratedValue - we either use UUIDs where approproate or some other hashing mechanism that is more applicaple to the project at hand. We set those in @PrePersist hooks, or during initialization.

[FroMage]

OK. I tested this with Long and String. The biggest problem is turning the String parameter from REST multipart into the ID type. For now I rely on a Type Type.toString(String) static method being present. Let me know if your ID types don't work, I'll find a better solution.