mehrdad70's avatar

Warning: 1265 Data truncated for column 'day' at row 1

hi , how i can fix dis error

Schema::create('sans', function (Blueprint $table) {
            $table->id();
            $table->enum('day' , ['saturday' , 'sunday' , 'monday' , 'tuesday' , 'wednesday' , 'thursday' , 'friday']);
            $table->string('sans');
            $table->timestamps();
        });
<div class="mb-3">
                <label for="sans"  class="form-label">Sans</label>
                <input type="text" class="form-control" id="sans" name="sans" value="{{old('sans')}}"  placeholder="sans">
            </div>

            <div class="mb-3">
                <label for="days"  class="form-label">انتخاب روز</label>
                
                <select name="days[]" class="form-control" multiple id="">
                    <option value="saturday">saturday</option>
                    <option value="sunday">sunday</option>
                    <option value="monday">monday</option>
                    <option value="tuesday">tuesday</option>
                    <option value="wednesday">wednesday</option>
                    <option value="thursday">thursday</option>
                    <option value="friday">friday</option>
                </select>
            </div>
    public function store(Request $request)
    {
        $days = implode("," , $request->days);
        Sans::query()->create([
            'sans' => $request->sans,
            'day' => $days
        ]);
        return back();
    }
0 likes
5 replies
johnDoe220's avatar
Schema::create('sans', function (Blueprint $table) {
            $table->id();
            $table->text('day' );
            $table->string('sans');
            $table->timestamps();
        });

You cannot store more that one value in an ENUM column

1 like
kokoshneta's avatar

Your day column is of type enum, which means it can have no other values than one of the options (day names).

In your store method, you’re imploding the day names, creating a string that can contain multiple names as a comma-separated string. That’s not a valid value for your day column. If you select two days in the form, the SQL will end up looking something like this (assuming that $request->sans is 12345):

INSERT INTO `sans` (`day`, `sans`) VALUES (`tuesday, thursday`, `12345`)

And tuesday, thursday is not a valid value for the day column, so SQL truncates it until it is valid, which in this case would be until only tuesday is left.

There is no way (at least not that I know of) to limit a column to being a string which can contain a comma-separated list of one or more out of seven possible values, but nothing else. The only way to do that would be to make it an enum column with all possible permutations as options, but that would give 5,040 possible enum values (I think?), which would be horrible design.

mehrdad70's avatar

@kokoshneta is this the right solution ?

foreach($request->days as $day){
            Sans::query()->create([
                'sans' => $request->sans,
                'day' => $day
            ]);
        }
        return back();
kokoshneta's avatar

@mehrdad70 Yes, that should do it. That will, of course, create multiple rows in the table, one for each day, which will make the table a normal pivot table. That is likely what you want anyway, as that will allow you to use Laravel’s built-in relation loading functionality more easily.

@johndoe220 There’s no reason to change the enum column to text – in fact, there’s good reason not to, primarily that you couldn’t make it part of an index if you did. You could change it to a varchar column, which would do the same, but it could still be part of an index, and it would also take up less space than text.

But there are good reasons not to do either but keep it as an enum column. For one thing, enum will take up less space than textual columns because the values are only stored once and then referred to by one-bit integers. And for another, defining the enum the way the question does, it can be accurately used for sorting in the desired order, which you wouldn’t be able to do at all with a textual data type.

Please or to participate in this conversation.