Schema post.title size

Recently i m working in a CMS based in ghostjs, and some characteristics and decisions of project let me consuse…

I hope this space help me to better understand and let me to chose right choices in this job.

Now i am intriged abount posts.title size, 2000 chars, this was a problem to me becouse generate a throuble in time to create a new field (subtitle) , mysql

Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

Have any reason to make this field very large ?

For comparison example, this text have 701 chars, 2000 is very large in principle.

Hi again @luizamboni :wink: The problem you are having with the maximum row size is the one we have meant to deal with in a long time. The posts table has reached it’s maximum capacity and all the fields that are there have the sizes which were needed by design.

To partially solve this problem 8 fields will be extracted into a separate table posts_meta with upcoming v3 release. You can temporarily use schema changes done in https://github.com/TryGhost/Ghost/pull/11102 to give space for your field. Fair warning :warning:, this is not a super final version so things might change, but if you absolutely need that additional field in posts table you can try it out.

Also would suggest avoiding modifications in core tables like posts, users etc. too much as it might become harder to keep compatibility in the future. I don’t know your exact use case in this situation, but maybe repurposing one of the existing fields like meta_description would solve the problem you are facing wihout a need to add new fields?

I create one migration to modify the title size to 2000 from 120 and after a migration to create subtatitle.

In my case, I’m migration data from a previous cms (build in house) and the size in this cms is 120, then are a size that already work and I not believe that increase much more.

I my mind its was a minor change compared to split table.

Thanks for reply, but I really appreciated understand why title field was modelled to be large. What was the situation.