PostgreSQL/TimescaleDB max identifier length

I ran into an issue where the persistence of my item failed, due to the fact that the UID of the items has more than 63 characters. Not a big issue: i’ve renamed the items with a shorter name and now it all functions correctly.

However, I would like to prevent this happening in the future. Is there somewhere in openHAB a configuration setting for the maximum length of an UUID?

No, not really.

Generally because Item Names have to be used so many places there tends to be a natural pressure to keep them relatively short and meaningful. Reading code with 63 character long variable names is hard.

I also suspect this limitation is going to be database engine specific so I’m not sure it would be appropriate to set a global limit. But it does make sense to perhaps add a warning log statement for those using PostgerSQL.

If you have explaining thing uid’s and explaining item uid’s the length grows very fast. I’ll create a rule that monitors my name lengths, just to be on the safe side :wink:

The whole point of an Item is to be an abstraction layer away from the Things. I can’t think of a single reason why any information about the Thing would be useful in the Item name. That information is already captured in the Link.

And it’s not unusual to need to change the Thing (e.g. replace a broken Zwave device with a Shelly device that switches on the exact same lamp. You should have to change the Item name and deal with updating everywhere that Item is used just because the smart plug changed (losing all your persisted history in the process).

From a rule, UI, persistence, semantic model, integration with Alexa/Google Home/Homekit, chatbots, and everything else what matters is the Item type, what it represents and possibly where the device is. Anything else in the Item name is duplicative at best and can get in the way of long term maintenance at worst. In fact, I even recommend against putting information about the Item type in the name. Usually you can tell what an Item is without it (e.g. if the Item name is plural, like “Lights”, it’s going to be a Group).

For example, one of my Items might be Switch_Zwave_Node2_Frontroom_Wallswitch1 but it’s actually named Frontporch_Light. That has everything I need to know about this Item to understand what it controls. In those rare cases where I need to know something else about it (e.g. that it’s linked to a Zwave device) I can find that out by looking at the Item’s Link, or looking at the Thing. And when I['m writing a rule or a UI widget, I don’t need to guess or look up the name of an Item. I can just guess what it’s called based on what it controls.