'name' column length in variables
Hi, This is more a policy thing then a bug, IMO. Drupal has some columns harcoded in length, most notably the 'node.type' column and the 'variable.name' colmn. I ran into a problem today again, with a contrib breaking because it made its variables like variable_get('usernodes_foo_' . $type) //where $type is the node type name. You get it, that can grow very long. Drupal exploded there completely, because MySQL choked on already existing types. There aer loads of ways around this: use shorter node types in my (cck) configuration,. Use shorter names that prepend the $type etcetc. But I am sure that a patch will not fix this. I mean, we can make the 'name' column longer, but there is a limit, we will hit at some time again. Making a field longer is IMO only patching the error, not the cause of the error. Any good ideas for this? Should we start on a unique_name($string, $length) function? A function that will create unique names? Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
On Sunday 19 March 2006 04:28, Bèr Kessels wrote:
There aer loads of ways around this: use shorter node types in my (cck) configuration,. Use shorter names that prepend the $type etcetc. But I am sure that a patch will not fix this. I mean, we can make the 'name' column longer, but there is a limit, we will hit at some time again. Making a field longer is IMO only patching the error, not the cause of the error.
Any good ideas for this? Should we start on a unique_name($string, $length) function? A function that will create unique names?
Bèr
Well, for variables, since most are tied to one module or another why not just give them a module namespace? variable_get('usernodes', 'myvar', $default); That does a better job of avoiding name collision than we have now and keeps each column shorter. I'm pretty sure someone had a DEP at one point to rewrite the variable system that touched on this. Whoever it is, I apologize for forgetting your name. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Well, for variables, since most are tied to one module or another why not just give them a module namespace? variable_get('usernodes', 'myvar', $default); That does a better job of avoiding name collision than we have now and keeps each column shorter.
I'm pretty sure someone had a DEP at one point to rewrite the variable system that touched on this. Whoever it is, I apologize for forgetting your name. :-)
It was Adrian, and Allie expanded on it (or the other way round). I think it tied a realm/domain to the variable, and was called cascading variables at one point.
Op zondag 19 maart 2006 15:49, schreef Khalid B:
It was Adrian, and Allie expanded on it (or the other way round). I think it tied a realm/domain to the variable, and was called cascading variables at one point.
Good news. Untill that is here, we will have to check manually that we do not insert too long strings into the database. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
I've hit that problem in several different places due to multibyte utf-8 chars what is sufficient as a node title or anonymous commenter name in latin letters is not enough at all when using arabic for instance, arabic names for cck types and fields will be more of a problem. cheers, Alaa -- http://www.manalaa.net "context is over-rated. who are you anyway?"
I've hit that problem in several different places due to multibyte utf-8 chars
what is sufficient as a node title or anonymous commenter name in latin letters is not enough at all when using arabic for instance, arabic names for cck types and fields will be more of a problem.
I think this is no longer an issue. In HEAD, and a few betas for 4.7, there is a change to force the charset for the tables to be utf-8. I think it was Adrian who committed it (or was it Steven?). Can either of you guys confirm whether this would solve the storage is 8 bits per character or not?
On Sun, 19 Mar 2006 14:08:06 -0500 "Khalid B" <kb@2bits.com> wrote:
I've hit that problem in several different places due to multibyte utf-8 chars
what is sufficient as a node title or anonymous commenter name in latin letters is not enough at all when using arabic for instance, arabic names for cck types and fields will be more of a problem.
I think this is no longer an issue. In HEAD, and a few betas for 4.7, there is a change to force the charset for the tables to be utf-8.
this wouldn't work with mysql 4.0 would it? cheers, Alaa -- http://www.manalaa.net "context is over-rated. who are you anyway?"
I'm dubious this would help even in 4.1 and after... This would only help us if MySQL stores UTF8 internally as UCS2 (i.e., two byte Unicode), or maybe UTF16 (i.e., 4 byte Unicode folded back to 2 bytes), since that would guarantee that each and every character would have 2 bytes reserved for it. I'm guessing, though, that when MySQL says the encoding in the DB is UTF-8, they mean that literally, and an Arabic glyph is going to take up 3 bytes of storage space, and an ASCII character will take up only 1. This is instead of the one byte that an Arabic glyph takes up in ISO-8859-6. So if anything, using UTF8 will make the problem worse. The real solution, I think, is to make the field width wider for 4.8 for everything, so that there's enough space for non-Latin scripts like Arabic. Rob Alaa Abd El Fattah wrote:
On Sun, 19 Mar 2006 14:08:06 -0500 "Khalid B" <kb@2bits.com> wrote:
I've hit that problem in several different places due to multibyte utf-8 chars
what is sufficient as a node title or anonymous commenter name in latin letters is not enough at all when using arabic for instance, arabic names for cck types and fields will be more of a problem.
I think this is no longer an issue. In HEAD, and a few betas for 4.7, there is a change to force the charset for the tables to be utf-8.
this wouldn't work with mysql 4.0 would it?
cheers, Alaa
Hi all, anyone looking for a way to contribute to the Invite module for 4.7 can check out the list of tasks I made here: http://drupal.org/project/issues?projects=20967&versions=10249&states=1,8,13... cheers, Robert
Alaa Abd El Fattah wrote:
this wouldn't work with mysql 4.0 would it?
Dunno. 4.1 is fine though. I wonder whether some people might instead need UTF-16, however. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
participants (7)
-
Alaa Abd El Fattah -
Bèr Kessels -
John Handelaar -
Khalid B -
Larry Garfield -
Rob Thorne -
Robert Douglass