[Proposal] Some/All fields in the database should be longer
There are many properties stored in VARCHAR(255) fields, which sometimes isn't enough. This already causes http://jira.xwiki.org/jira/browse/XWIKI-883 . Changing to variable length field doesn't have any major side effects, as I know. As pro arguments: 1. The size of the database will not increase 2. There are already some fields stored as mediumtext and longblob, so it's not something new in the database 3. The fewer limits there are, the better 4. Issues like XWIKI-883 will be fixed ... and maybe more Is there something I'm missing that prevents this? -- http://purl.org/net/sergiu
5 days without an answer. So, everybody agrees? On 2/23/07, Sergiu Dumitriu <[email protected]> wrote:
There are many properties stored in VARCHAR(255) fields, which sometimes isn't enough. This already causes http://jira.xwiki.org/jira/browse/XWIKI-883 . Changing to variable length field doesn't have any major side effects, as I know.
As pro arguments: 1. The size of the database will not increase 2. There are already some fields stored as mediumtext and longblob, so it's not something new in the database 3. The fewer limits there are, the better 4. Issues like XWIKI-883 will be fixed ... and maybe more
Is there something I'm missing that prevents this?
Hi Sergiu, I believe there are some limits on some databases as to how many LONG VARCHAR columns exist. At least for DB2 (which I know we don't officialy support, but I believe I've got it mostly working), columns longer than 32k must be set as CLOB rather than VARCHAR. So I don't have a problem with making the columns longer by default, but still think some limits aren't too bad. "Sergiu Dumitriu" <[email protected]> 02/28/2007 03:05 PM Please respond to [email protected] To [email protected] cc Subject [xwiki-dev] Re: [Proposal] Some/All fields in the database should be longer 5 days without an answer. So, everybody agrees? On 2/23/07, Sergiu Dumitriu <[email protected] > wrote: There are many properties stored in VARCHAR(255) fields, which sometimes isn't enough. This already causes http://jira.xwiki.org/jira/browse/XWIKI-883 . Changing to variable length field doesn't have any major side effects, as I know. As pro arguments: 1. The size of the database will not increase 2. There are already some fields stored as mediumtext and longblob, so it's not something new in the database 3. The fewer limits there are, the better 4. Issues like XWIKI-883 will be fixed ... and maybe more Is there something I'm missing that prevents this? -- http://purl.org/net/sergiu -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Hi. Sergiu Dumitriu wrote:
There are many properties stored in VARCHAR(255) fields, which sometimes isn't enough. This already causes http://jira.xwiki.org/jira/browse/XWIKI-883 . Changing to variable length field doesn't have any major side effects, as I know.
As pro arguments: 1. The size of the database will not increase 2. There are already some fields stored as mediumtext and longblob, so it's not something new in the database 3. The fewer limits there are, the better 4. Issues like XWIKI-883 will be fixed ... and maybe more
Is there something I'm missing that prevents this?
1. varchar(255) is supported across all db 2. I think there are some reasons that hibernate uses 255 as default length of string. 3. biger types (clob, text) in many db has less functional possibilities (ex: mssql) and less performance. 4. 255 is a performance barrier for some databases (mysql <5.0.3 and some other db has a 255 length limit of varchar) A good discussion of this problem is here: http://osdir.com/ml/lang.groovy.grails.devel/2007-01/msg00029.html So i think varchar(255) is normal and safe for many core xwiki fields. (doc.names, etc). XWIKI-883 can be resolved by change of StringProperty to LargeStringProperty in Users/GroupsClass. (see attachment in jira) Or we can rename LargeStringProperty to StringProperty :) For what issues/fields else length increase can be useful? PS: All this has no sense in XWikiJcrStore :) -- Artem Melentyev, UralSU
participants (3)
-
Artem Melentyev -
Sergiu Dumitriu -
Shawn Lauzon