When I created MUC room which name is over 50 length via REST-API-plugin, API returns 200 response but I found below log in Openfire log.
2019.06.18 04:57:03 ERROR [Jetty-QTP-AdminConsole-2127598]: org.jivesoftware.openfire.muc.spi.MUCPersistenceManager - ERROR: value too long for type character varying(50)
org.postgresql.util.PSQLException: ERROR: value too long for type character varying(50)
...
I think the limit of room name length is too short if managing many rooms flexibly.
In RFC3920, node identifier can be up to 1023 bytes.
RFC3920 says,
Each allowable portion of a JID (node identifier, domain identifier,
and resource identifier) MUST NOT be more than 1023 bytes in length,
resulting in a maximum total size (including the '@' and '/'
separators) of 3071 bytes.
That’s a decision made many, many years ago, by people that have long left the project. I often see database columns that hold JID-part values to be shorter than the corresponding JID parts. I assume that this is done to not introduce very hefty indexes for things like unique checks.
The REST API should return an error, if the room wasn’t created successfully. I’m unsure if changing the database column definition benefits anyone but you: I’ve not heard anyone, ever, raise this issue.
Technically it makes sense though, no?
I mean having the database column in sync with the allowed local part of a JID.
Although I cannot foresee the performance impact.
Sure. I looked into this briefly back in 2012, but decided it wasn’t worth the effort at that time. Note that database mechanics might have changed considerably since.
REST API plugin seems to have a problem about creating room error handling. Despite room name length 50 over and MUCPersistenceManager throws error, API returned 200 and Openfire loaded the room data on memory.
Anyway, I will change the ofmucroom table definition with my plugin (/src/database/xxx_postgres.sql).