Support the ongoing development of Laravel.io →
Requests Input Eloquent
Last updated 2 years ago.
0

@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();
Last updated 9 years ago.
0

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'];

0

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
Last updated 9 years ago.
0

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;
Last updated 9 years ago.
0

@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.

0

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'];	
0

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();
0

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

0

Okay, I figured it out. And I feel dumb. The flow of my code is to first add a new payment and then update any existing payments. The problem was is that I collected the existing payments to update immediately after adding the new payment, so my update code with essentially clearing the data of the payment that was just added.

Thanks guys!

0

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.

0

Sign in to participate in this thread!

Eventy

Your banner here too?

anakadote anakadote Joined 10 Jul 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.