Closed jjeising closed 6 years ago
If the change to text has no further implication i would vote for that as we get user input here and it is not specified that this filed has a max length. @a-tze pointed out that we may need to cap it at some point before passing it to ffmpeg but IMHO this should happen at the job level. Not having the fulltext means we can also not add the fulltext to media.ccc.de or other publishing targets.
Thinking about all implications, I'm also for changing the data type to text. This leads to "problem solving" on the side of property consumers, not in the source. Postgres handles this efficiently, someone told me a while ago. I also dont think that the value is used in JOINs or similar.
@jjeising will you have time to fix this before bits und bäume or should i request a change in the schedule?
The import fails silent and without further warning, following tickets will not be imported, if a property value (e.g. ticket description) exceeds 8196 characters.
Possible options are an extended validation before import (including XSD validation), truncating values or/and changing property value type from
character varying
totext
.