@anakadote

try this,

$payment = new JobPayment;

$payment->amount = $request->input('payment_amount');

$payment->note = $request->input('payment_note');

$payment->date = $request->input('payment_date');

$payment->save();

DrPrez said:

http://laravel.com/docs/5.0/eloquent#mass-assignment

Hint: $fillable

Thanks, DrPrez, but the attributes aren't being assigned via mass assignment, so the $fillable property isn't applicable here. For sanity sake I do only have the following set as 'guarded':

protected $guarded = ['id', 'job_id', 'updated_at'];

Really weird one. If the log shows you that query with all bindings, and it still doesn't save the data, then it's really weird.

Suggestions:

1. Could you try to launch that SQL directly via phpmyadmin or something?
2. Column types - are there any conversions that could fail?
3. Crazy one: check if you're looking at the same database/table

I have confirmed that the model is be updated with the given data before the call to save(). And it's definitely the same database and table. I just can't figure out why the query log shows the query with its bindings, yet the columns are still empty.

Another strange thing: I can successfully update the empty table row:

// Update payments
$payments = $job->payments;

if($payments){
    foreach($payments as $payment){

        $payment->amount  = $request->input('payment_amount_' . $payment->id);
        $payment->note    = $request->input('payment_note_' . $payment->id);
        $payment->date    = $request->input('payment_date_' . $payment->id);
	    
        $payment->save();
    }
}

Here is the table export:

CREATE TABLE `job_payments` (
  `id` int(10) unsigned NOT NULL,
  `job_id` int(10) unsigned NOT NULL,
  `amount` decimal(7,2) NOT NULL DEFAULT '0.00',
  `note` varchar(255) NOT NULL,
  `date` date NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00'
) ENGINE=InnoDB DEFAULT CHARSET=latin1;


ALTER TABLE `job_payments`
  ADD PRIMARY KEY (`id`),
  ADD KEY `job_payments_job_id_foreign` (`job_id`);


ALTER TABLE `job_payments`
  MODIFY `id` int(10) unsigned NOT NULL AUTO_INCREMENT;

ALTER TABLE `job_payments`
  ADD CONSTRAINT `job_payments_job_id_foreign` FOREIGN KEY (`job_id`) REFERENCES `jobs` (`id`) ON DELETE CASCADE;

@anakadote - just for the sake of testing, could you try to add them as $fillable fields? I have a feeling that it works differently with sub-models like this, maybe it launches create() under the hood.

PovilasKorop said:

@anakadote - just for the sake of testing, could you try to add them as $fillable fields? I have a feeling that it works differently with sub-models like this, maybe it launches create() under the hood.

I had high hopes for this! But unfortunately got the same result.

protected $fillable = ['job_id', 'amount', 'note', 'date'];	

And I tried setting job_id explicitly but no dice either:

$payment          = new JobPayment;
$payment->job_id  = $job->id;
$payment->amount  = $request->input('payment_amount');
$payment->note    = $request->input('payment_note');
$payment->date    = $request->input('payment_date');
$payment->save();

For what it's worth, using the same exact code in a database seeder does work.

So wait, @anakadote - you're saying that the last DB::getQueryLog() entry is totally filled with bindings? Cause from that end it totally should work, otherwise without fillables (or guarded property) it wouldn't even fill those bindings.

I assume the problem is really a small one - you just have to find where you're missing some "small detail" which changes behaviour.

If DB::getQueryLog() doesn't show anything extraordinary, then I would go and add dd() functions to Laravel's core to find out what is the actual final query.