I think there will be better to change type of "type_name" field from varchar to int. Here is some reasons:

  1. We have Label of content type and we can change it any time. But the name of content type is create on start and not changable.
  2. Names of content type can contain only ASCI characters and we must to create some monstrosity names in our national languages. See issue Unfriendly names for fields with non-ASCII labels.
  3. What about performances? Primary key varchar(32) must be larger and very slower than int. I always know that when primary key is smaller, that is better for speed.
CommentFileSizeAuthor
#3 cck-erd_0.png52.11 KBmki

Comments

mki’s picture

mki commented

Can someone concern this issue please? I think this is very important potential modification.

mki’s picture

mki commented

Another thing that I noticed: when we add existing field to content type, CCK showing label of existing fields from "node_field_instance" table, where labels of fields are assing to specific content type. CCK just take one of them. Where are general labels of fields? There should be in "node_field" table, but they aren't.

To sum up, I conclude that the name of content types and fields should be turn to integers. Then ASCII names disappear as i18n barrier and in general. This will complete seperate user from technical question.

What to do with table names of content type? Maybe they can contain integers too.

mki’s picture

mki commented
StatusFileSize
new cck-erd_0.png52.11 KB

New database schema for CCK is attachement. Red mark changes.

Torenware’s picture

Torenware commented

I get confused by some of the "type" fields in CCK, so tell me if I'm wrong here.

Since CCK field types are extensible (I've done so for CiviNode and other CiviCRM related work), someone creating a new type would need to create a new 'define' to make their new types into the database. If the fields in the schema you want to change are among the fields in a custom type, then it becomes very messy: it's very hard to coordinate how different modules assign "magic numbers" to their new types, and most likely, we'd end up with some pretty subtle bugs when two different modules tried to assign their types to the same number.

ascii text, on the other hand, is a lot easier to manage, and modules like 'Views' have had a good history of managing conflicts between modules. A similar approach for CCK would work well also. The performance issues might or might not be an issue, but I'd personally want to see proof that this is really a practical limitation to CCK as things currently stand.

It probably makes sense to put only "identifiers" (i.e., 7-bit ascii) in for type names. I'm assuming that the label can contain arbitrary UTF-8 data, which would be correct for text you wanted to localize.

mki’s picture

mki commented

I know that my suggestions are not complete perfect and definitive.

But I attempt to solve problem, witch in plain form is: when someone create new content/field type in Chinese, labels of her/his type must be completely diffrent than system name of this types. In this case, (s)he have to use some ACSII-language, not own. As you can see, character identifier of content/fields type are unacceptable, becouse this force users to use ASCII strings, so where is internationalization? As long as we will use ASCII strings to identyfy anything, idea of internationalization will be ruin.

Another thing is that current names of content/fields types must have technical, computer-friendly form and are just uncomfortable.

I agree that numbers as identifiers of content type may look a bit inelegant. I don't think that diffrent modules can't collide when trying to use the same number of type, becouse SQL accept only unique values of primary key. So when some module is installed, integers of created content types may be for example remember by module as configuration values. Integers of field types assign to created content type will be store in "node_field_instance".

Thank you that become interested in my issue becouse I don't know Drupal core enough and I want to talk this over with somebody. Maybe JonBob can tell something about this becouse this issue concerns core of CCK.

RayZ’s picture

RayZ commented

I believe the intention is that you can create them as ASCII and then change them to whatever you like. The names in the database retain the original ASCII values, but the user visible labels get updated. Does this provide what you want?

I'm pretty sure this should be marked as "won't fix".

mki’s picture

mki commented

RayZ, the solutions that you suggest is ineffective. Current ASCII names are widely used to identyfy types of content/field and that is why they must have right meaning. But what ASCII names should be invent if labels in no way can be "translated" into ASCII strings? How administrator can call and identify this types?

Moreover translation labes to English system names is out of the question becouse is very difficult and require put a lot of effort. It's not about translation such things like "book" or "ballpoint", but frequently the point are complicated terms in a field of knowledge.

I'm not so sure that this merit "won't fix". I think some change are needed becouse current state prevent users from using their national languages and this is contrary to internationalization.

RayZ’s picture

RayZ commented

Well, based on JonBob's comments in Unfriendly names for fields with non-ASCII labels, I believe he understands the issue and that he chose this approach intentionally. So maybe "by design" would be more appropriate. Comment #2 in particular explains his reasoning.

Seems like for those using Latin scripts the current approach is an improvement over flexinode's use of integers. But for those using other scripts, it is actually less satisfactory.

Here's a possible compromise. Instead of the current approach of trying to create valid ASCII names from non-ASCII labels, maybe CCK could detect the non-ASCII label and then simply generate a flexinode style 'content-type-4' or 'field-34' internal name in those cases. Just an idea.

RayZ’s picture

RayZ commented

In the meantime, can't you just manually name things initially as 'content_type_4' and 'field_23', to create the types and fields. Then once they are created, change the user visible labels to your desired labels? I agree it's a pain to have to go through this two step process, but does it not accomplish what you want? (an honest question ... I haven't actually tried it, since I don't need non-ASCII labels)

mki’s picture

mki commented
Component: General » content.module
Status: Active » Closed (works as designed)

Thank you RayZ that you devoted time to this problem.

Of course you have damn right, at present in creating my contents and fields schema I must use precisely this method that you provide. As you said, this is less sarisfatory.

I think that JonBob in quoted comment don't have well enough idea to solve this problem and that's why Unfriendly names for fields with non-ASCII labels is still active. Therefor I decide provide some solution, maybe not perfect and with difficult acceptable from current CCK and Drupal core desing point of view.

The rub is that this "internal places", as called this JonBob, where we use ASCII names, in fact aren't "internal" in case of CCK - this is area that is create by frontend-user (not developer), where the rule isn't to take English for all identifier or comments in PHP and SQL.

The only thing I can do is waiting for reaction from CCK developer, and maybe they can offer some not half measure, but real way out.

Thank a lot RayZ.

mki’s picture

mki commented
Component: content.module » General

This is the list of issues in status "by design" that are in relationship with this issue:

In relation to above issues I think we need some constant symbolic name for type of content and field types without meaning (like integer) with assigned to it some full-changeable label.

Perhaps there will be problem with comfortable identification of tables or fileds in database and themes files, but maybe exist some elegant solution for this. For example, there could be some configuration variables in database for all modules that will tell witch integers correspond to content or filed types for this module or create in CCK. And theme files could be moved to database as configuration values for content or field types. That's only suggestions.

mki’s picture

mki commented
Title: type_name and field_name from varchar to int » Internal names problem (first look at the last comment)
Status: Closed (works as designed) » Closed (won't fix)

I maked an attempt to solve some problems, but I come to the conclusion that my solutions isn't good becouse translated names may appear for example in path, just see my another issue I18n and L10n for path. So if this symbolic names will be integer, above-mentioned issue will not work. So at this point I accede to use in this symbilic (internal) names just UTF-8, if this is possible of course.

Mayby this looking ridiculous that I discuss with oneself, but this thoughts could be useful for someone who try to improve CCK.