Users and Groups properties are stored as LargeStringProperty. Why?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Users and Groups properties are stored as LargeStringProperty. Why?

Marius Dumitru Florea
Hi devs,

As you probably know, UsersClass and GroupsClass overwrite the newProperty
implementation from ListClass and hard code the usage of
LargeStringProperty. The implementation from ListClass takes into account
the relational storage and multiple selection meta properties while
UsersClass and GroupsClass are completely ignoring them. Do you have any
idea why? It's been like this for more than 11 years..

The hard coded LargeStringProperty was introduced in
even though at that point ListClass#newProperty was already taking into
account relational storage.

As for the hard coded StringProperty that was before it, it is since the
start of the XWiki history I can access on GitHub, same as the
ListClass#newProperty implementation that take into account relational

So I have no idea why we had to overwrite ListClass#newProperty in
UsersClass and GroupsClass.

The big problem is that in the current state the Users and Groups
properties cannot be filtered in Oracle because they are stored as CLOB.
See and .

Fixing this by removing UsersClass#newProperty and GroupsClass#newProperty
requires a migrator and breaks existing queries that join the
LargeStringProperty table to get the users and groups values. Is it
acceptable to break those queries? I'm afraid there are quite a lot of
them, especially since we have examples of such queries on .