【问题标题】:Laravel: String data, right truncated: 1406 Data too long for columnLaravel:字符串数据,右截断:1406 列数据太长
【发布时间】:2018-07-06 18:24:59
【问题描述】:

我有一张桌子,里面有一列“酒店”。该项目是在 Laravel 5.4 中创建的,所以我使用了 Migrations。

$table->string('hotel', 50);

这是 MYSQL VARCHAR (50)。它工作得很好,因为在我开发时,我使用了短的酒店名称,例如 “HILTON NEW YORK 5”*。

现在项目正在制作中,客户问为什么他们不能输入长酒店名称。我已经用 “Long long long long long long long long long long long andvery-very-very long hotel name 5 stars”这样的模拟酒店名称对其进行了测试

它给了我一个错误:

"SQLSTATE[22001]: 字符串数据,右截断:1406 数据太长 第 1 行的“酒店”列“

我在我的 Sequel Pro 中打开了数据库并更改了它

  • 首先到 VARCHAR (255)
  • 然后转文本

每次更改后,我都使用相同的“Long long long long long long long long long long and very-very-very long hotel name 5 starts”对其进行测试,并得到相同的错误(见上文)。

我已经检查了列的类型

SHOW FIELDS FROM table_name

它给了我

字段 |类型

酒店 |文字

所以字段的类型确实是“文本”(65 535 个字符)。

也许它与我在开始时设置 VARCHAR (50) 的 Laravel 迁移文件(见上文)有关?但我无法在生产环境中重新运行迁移,因为该表现在有数据。

不胜感激。


更新: 我发现它实际上在数据库中保存了那个长酒店名称。但是用户每次提交表单后仍然会遇到这个烦人的错误......

【问题讨论】:

  • 您当然可以创建迁移来更改字段类型。只要它是类似的东西,它应该不是问题。
  • 和往常一样,在您的本地副本上试一试以防万一,但我不明白为什么它不起作用。
  • 大家好。谢谢你。正如 Alexey 在下面的回答中解释的那样,我创建了一个新的迁移并运行它(在本地),但是每次提交表单时仍然会出现错误......:(

标签: php mysql laravel text types


【解决方案1】:
public function up()
{
    Schema::table('news', function (Blueprint $table) {
        $table->text('content')->change();
    });
}

public function down()
{
    Schema::table('news', function (Blueprint $table) {
        $table->string('content', 65536)->change();
    });
}

【讨论】:

    【解决方案2】:

    如果'text'数据类型不起作用,则将数据库中列的数据类型更改为'longtext'

    【讨论】:

      【解决方案3】:

      这个错误的解决方法 "SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'hotel' at row 1" 打开 Mysql 并单击该列最前面的更改按钮并设置长度/值 = 111

      【讨论】:

        【解决方案4】:

        我将图片以 base64 格式存储在文本列中,因此出现 SQL 错误:

        SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'picture' at row 1 
        

        我的迁移是

        $table->text('picture')
        

        然后我把de栏图片改成:

        $table->mediumText('picture')
        

        我意识到文本列只允许存储 64 KB

        文本:65,535 个字符 - 64 KB 中文本:16,777,215 - 16 MB 长文本:4,294,967,295 个字符 - 4 GB

        欲了解更多信息,请访问:understanding-strorage-sizes-for-mysql-text-data-types

        【讨论】:

        • $table->text('picture') 解决了我的问题
        【解决方案5】:

        将列的数据类型从字符串更改为文本并且不给出长度。

        $table->text('hotel')->change();
        

        【讨论】:

          【解决方案6】:

          将列的数据类型从字符串更改为文本并且不给出长度。

          【讨论】:

            【解决方案7】:

            在您的本地开发中,尝试将列类型更改为:

            $table->longText('columnName')
            

            来自您的迁移文件。这为我解决了它。但是,如果您已经上线,请按照 Alexey 的建议创建一个新的迁移,然后使用 longText() 列类型。

            【讨论】:

            • $table->text('columnName') 对于大多数情况应该足够了
            • longText() 比 text() 拥有更多的数据。所以,他知道他将处理非常大的文本,longText() 可以完成这项工作。
            • Long text will hold up to 4GB of text。酒店名称绝对不会那么长。 text() 在这里会很好。如果它没有,你会想在去 longText() 之前碰到 mediumText()。
            【解决方案8】:

            将列的类型从string 更改为text

            然后使用 php artisan migrate:refesh 运行迁移刷新

            【讨论】:

            • 为什么改变类型会有帮助? OP 提到“我在我的 Sequel Pro 中打开了数据库并首先将其更改为 VARCHAR (255) 然后更改为 TEXT 每次更改后我都使用相同的“Long long long long long long long long long long long and very-very-very long”对其进行了测试酒店名称 5 开始”并得到相同的错误(见上文)。”
            • 迁移后数据丢失:刷新!!
            【解决方案9】:

            您需要创建一个新的迁移,使用composer du 命令注册它并运行php artisan migrate 命令来更改列的类型:

            Schema::table('the_table_name', function (Blueprint $table) {
                $table->string('hotel', 255)->change();
            });
            

            【讨论】:

            • 嗨,阿列克谢。如何在不丢失所有输入数据的情况下在服务器上运行迁移。
            • 这就是迁移的目的。如果您添加新的迁移只是为了更改列类型并运行php artisan migrate 命令,则不会丢失任何数据。不过看起来你是新手,所以我真的建议你先在本地机器上练习并备份数据。
            • 1) 我应该在迁移文件中向“ public function down(){ } 写一些东西吗?2) 尝试运行迁移并出错“更改表“tours”的列需要Doctrine DBAL;安装“教义/dbal”。将安装它并在本地服务器上运行。
            • 是的,你需要安装包。此外,您应该修改up() 方法中的列,在down() 中您需要将其修改回现在的状态。运行php artisan migrate:rollback 命令时会执行down() 方法。
            • 您的回答确实有效,谢谢。这是另一个名为“previous_tours”的表,其中“酒店”字段也将以相同的方式重新排列。
            猜你喜欢
            • 1970-01-01
            • 2021-09-02
            • 2021-04-03
            • 2020-06-27
            • 2021-05-09
            • 1970-01-01
            • 1970-01-01
            • 2012-02-11
            • 1970-01-01
            相关资源
            最近更新 更多