Looking at RTs database schema (attached in full as the patch is actually
larger) there are the following table/column combinations which are of type
CLOB:
Currently all of these columns are of type CLOB. I suggest that moving the
User table values to VARCHAR(4000) to store 4k of data within them COULD
be a good thing. Can anyone see issues with this?
Users.Comments “According to wc this email is only 1743
characters”
Users.Signature “Even my awful .signature is only 524 Characters”
Users.FreeFormContactInfo
Users.PGPKey
This will allow common LIKE queries to work with the Users tables.
Resulting in less work modifying DBIx::SearchBuilder to handle the CLOB
data type (this actually won’t result is less work - but means that some
functionality will work without changes to SearchBuilder).
NB:- the attached schema.Oracle file still has the Users table using CLOB
just in case people don’t like the idea of changing.
Looking at RTs database schema (attached in full as the patch is actually
larger) there are the following table/column combinations which are of type
CLOB:
Currently all of these columns are of type CLOB. I suggest that moving the
User table values to VARCHAR(4000) to store 4k of data within them COULD
be a good thing. Can anyone see issues with this?
Users.Comments “According to wc this email is only 1743
characters”
Users.Signature “Even my awful .signature is only 524 Characters”
Users.FreeFormContactInfo
Users.PGPKey
That all makes sense, though I can’t see when any of these would ever be
searched with a LIKE
This will allow common LIKE queries to work with the Users tables.
Resulting in less work modifying DBIx::SearchBuilder to handle the CLOB
data type (this actually won’t result is less work - but means that some
functionality will work without changes to SearchBuilder).
NB:- the attached schema.Oracle file still has the Users table using CLOB
just in case people don’t like the idea of changing.
Currently all of these columns are of type CLOB. I suggest that moving
the User table values to VARCHAR(4000) to store 4k of data within them COULD be a good thing. Can anyone see issues with this?
Users.PGPKey
if this is storing a signed pgp key, 4000 characters seems a little on
the small side.
This will allow common LIKE queries to work with the Users
tables. Resulting in less work modifying DBIx::SearchBuilder to
handle the CLOB data type (this actually won’t result is less work -
but means that some functionality will work without changes to
SearchBuilder).