Now 'config' table has some mysteries. Here is an example of some fields from this table:
conf_name - varchar(25)
conf_title - varchar(30)
conf_desc - varchar(50)

Could anyone explain why these three fields should have different length? I believe, that conf_title and conf_name should be also varchar(50) as conf_desc. For example:

if i would like to name config, like this:
_MI_DISCOGRAPHY_CONFIGS_UPLOADS_DIR_TITLE

I explain this constant:
_MI - module information
_DISCOGRAPHY - module name
_CONFIGS - separator from other constants, that this one will be used in configs
_UPLOADS_DIR - config name. This config defines title of uploads directory
_TITLE - define that this constant is title (not description)

43 chars! And I couln't understand why I should shorten it to _MI_DISCOGRAPHY_C_UPLOADS_1_T...

This is only one example. Maybe someone should recheck all properties in all tables and fields?

But maybe there is an explanation for these lengths?

The likely explanation is that whoever wrote that originally decided those column widths were the right ones to use, and no one has ever changed them.

I think they should be larger too.

personally i think fields like that should be 'text' attribute. it's better for indexing and searching..

varchar adds extra chars to the field anyway which uses up more space in the db than the say 50 chars that varchar(50) displays. at least with 'text' whatever size you set, is the size it actually uses

Why is "text" better than "varchar" for indexing and searching?

Actually, the text and varchar types both add extra bytes to keep track of the data length:http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Quote:

What? As i can understand data storage in mysql, best performance in this case would be to use CHAR (bigger files, but better performance) (if db table is MyISAM type). How many rows we could have in config table? Several hundreds? Even if we have several thousands still it would be better to use char (if we do not care about some additional kilobytes in mysql). But this place isn't worth that we discuss it :) it's too small, it's just a question of greater length.

Quote:

True of many things in life

I agree that the conf_title and conf_desc fields should be longer - I have reached the limit a couple of times, too.

The conf_name, however, should not, as it is used in the code and I believe that $xoopsModuleConfig['prefix_context_name_and_usage_and_more'] can ALWAYS be shortened to something that still is of use to the code-reader.

Especially the practice of prefixing module config names is unnecessary in my opinion. Database tables and Smarty templates can conflict with other modules, if not prefixed, but configuration items cannot (they are bound by module) so "max_items" is just as useful as "mymodule_frontpage_max_items" - if not even better, since it is shorter and easier to remember.

Regarding the field type, I find that there is a reason why varchar's exist and if text was better, it would be used and encouraged more. Searching and indexing text fields is NOT better than varchar's (in my perception) when we talk KEY indexes. Of course, text in MyISAM can be fulltext indexed, but that only makes sense with large amounts of content in many words. Conf_title and conf_desc fields are names of constants and thus always in one word and should not be too long for the same reasons as the above (however, it should be prefixed to avoid conflicts with other modules - however unlikely it is that it should happen)

"too long" has moved since the config table schema was created and it could be a good move to enlarge the fields' lengths, agreed (and it was actually done in 2.2.x as one of the smaller changes).

So can we expect this change in new XOOPS version?