Article length

[Greybrow]

Hi.
I just tried to post an article with more thant 64KB of text. It has been cut without warning.
I've changed in 'body' column in tp_articles to "longtext" from "text" to make it work.
Could it be changed to this length in next version?

[bloc]

Longtext is a very large amount..I am not sure its really needed. If a article is that large, its also taking its time to download - especially for dial-up users. So it might be wise to chop up articles that long just for webpage efficiency's sake.

How about others? Do you often hit the 64k border...?

[G6Cad]

Havent manage to reach that far yet though ^64k letters is some article to, perhaps a book or a manual for something it might reach that limit 

[Greybrow]

It's a Liero weapons encyclopedia and it's about 115KB. SMF compresses it to about 36KB. So no problem at all.
If you care for dialups, then all pics should be removed, since they can't be compressed and usually take much more space.
Also longtext doesn't just take all the place in mysql database, when it's not filled. So still no problems.

If not longtext then what?
Still if you don't want it, then why there is no warning when it's cut?

Longtext is a very large amount..I am not sure its really needed.

btw remember?

640K of memory should be enough for anybody.

[bloc]

If you include big pictures they can be turned off in the browser..the text is downloaded regardless.

About the cutting-off, thats done in mysql, TP would need to check its length first to give a warning. I can add that.

I need to read up on if there are any downsides..but if not it might be  good to make it longtext.

[Blue Steel]

This has always been the hastle that i've found with Storing stuff in the DB's its very limiting in size.. most Articles that I ever submitted on the Knowledgebase add on when i was using php I was always running out of space.. which is why I wish there was a way to have it save them to disk instead of DB .. BTW I did get larger articles that worked fine (all be it slower and more sql access time with longtext field type

It also makes for bigger backups of the DB if you have large articles and pici's in the articles.
especially if you have a lot of them.. Yes i know thre are pro's and Cons about using DB's to store ALL your web page data.. but i think that the more complex the system is the more that can go wroong

[Greybrow]

There are pros and cons to everything.
But it's important to have a choice

I'm a bit worried that after upgrade it would be changed back from longtext to text.
But I'm too paraonoid to not to have backups

[Thurnok]

Just an FYI..

The additional storage requirements of LONGTEXT vs. TEXT is 2 bytes.  So, for all your  articles that are <= 64K you will add an additional 2 bytes of storage.  So if you had 200,000 articles, you would add an additional 400k bytes to your storage.  This is an extreme number of articles, however.

I doubt most websites would keep more than maybe 200-400 articles at best, so a more practical space increase might be simply 800 bytes.  A very reasonable tradeoff in my opinion.

As far as efficiency, TEXT, MEDIUMTEXT, and LONGTEXT all have the same efficiency quotient based on size, so all 3 with the same amount of text (30k for example) would load equally effecient.  Only the size will be a factor.  It doesn't sound like most people would use more than a TEXT size article, and even those that will, will probably only have a few that are greater in size.

It sounds like a reasonable change.

[bloc]

Yes..I come to the same conclusion after reading up a bit. Thanks for explaining this.

Added to the 0.9.5beta.