Default length of text field(multiline)

[RAJ]

can you please let me know the length of string that the description or text field(multiline) field currently supports?

[Nic Brough -Adaptavist- · Accepted solution]

In useful terms, "big enough".  It can hold more text than any human would find readable.

[Tyler C. Borg]

After researching I found the answer Atlassian OnDemand uses Postgresql https://confluence.atlassian.com/cloud/database-and-ip-information-744721662.html.
The limitation for Postgresql text fields is approximately 1 GB. http://www.postgresql.org/docs/8.4/static/datatype-character.html
Hope this helps Arjun.

Thanks and Regards,
Tyler Borg

[Michael Vlasov]

It are unconfirmed assumptions. There should be official documentation for this.

[Tyler C. Borg]

I understand you must not be a technical user so this won't make sense to you but I am designing an internal database that we transfer data from the JIRA CLOUD API, and when I make SQL table columns they want an exact length. Big Enough is not a valid size for a nvarchar column. For purposes of data storage and compatibility in the data transfer application exact length is a very essential piece of information.

[Fabio Manzoni]

Hi @Janco Hoekstra 

I found this documentation.  Check the item jira.text.field.character.limit 

https://confluence.atlassian.com/adminjiraserver/configuring-advanced-settings-938847828.html?_ga=2.263389068.1691819613.1597626978-1478559027.1570682324

[Janco Hoekstra]

I sure agree to the human factor, uunless this human is willing to do harm. What about someone who wants to serios slow down the system or provoke something like a crash?

By filling up the textfields your database is going to be an enormous monster that is practicaly not managable anymore.

[Nic Brough -Adaptavist-]

Same answer applies.  If your add-on is dumping over-large data into a field, it's a complete waste of time and you're doing the wrong thing.

[Michael Vlasov]

@Nic Brough [Adaptavist] as an add-on developer I have to know such information to apply these limits to the data which was provided by my add-on and is going to be saved into the standard custom field.

[Nic Brough -Adaptavist-]

Nearly. What I'm trying to say is that trying to put a number on it is pointless. 4000 isn't enough, I know of many systems that have gone over that. But equally, you won't find systems that use the *physical* limit because humans simply won't enter 65-ish copies of the world's best-selling book (uncompressed), you can be pretty sure they won't read all of it, and the web-server is likely to time-out before rendering it all. But you can't guarantee where it will land between " a couple of words" and "a long rambling description of something". So, yet again, I have to say "don't limit it". It's the wrong thing to do, and it's simply not necessary in any modern database anyway.

[Nic Brough -Adaptavist-]

I'm technical enough to understand that, but the answer is still "big enough". What you're trying to do is limit something that you don't know to a number you can't know. The really simple answer is that you have to assume 2^32-1 bytes, because the field is technically only limited by the size of the database field. (Oh, I'm also technical enough to point out that someone is probably doing something very wrong if they are asking you for "an exact length". It strongly implies someone has done a database introduction course and not quite got it)

[Nic Brough -Adaptavist-]

Why? It's utterly useless information because over-large text fields are useless to you.

[Tyler C. Borg]

I also need an answer to this question in the form of a specific length.