Laravel $model->update() and $model->fill()

I just found Laravel’s $model->fill() and $query->update() on a couple of Stack Overflow posts.

The first operates on a model and takes an array (or perhaps a collection?) of updated values, and updates the model’s fields based on the values of the array. (I assume it does *not* automagically save the model – haven’t checked that yet.)

The second replaces get() in a query and updates the model (or models) returned by the query, without ever actually loading them (so without triggering saved or updated model events), and saves them in the database.

But it can also update just one model, eg:

$partner = Partner::find($partnerData['partner_id']);
$partner->update($partnerData);

They’re both described in the Laravel docs for Eloquent.

Advertisements
Laravel $model->update() and $model->fill()

Laravel Socialite driver not supported

I’m trying to get an existing Laravel 5.1 app to work with Okta authentication for my day job, using tequilarapido’s socialite-okta. But I’m getting errors. So I tried a simple proof-of-concept app, thus:

composer create-project laravel/laravel tequila-demo 5.1.*
cd tequila-demo
composer require tequilarapido/socialite-okta

…and then I did the socialite-okta setup:

# Added Tequilarapido service provider and Socialite alias to config/app.php
# Added 'okta' config to config/services.php and .env

…and finally I did the Laravel Social Auth setup:

# Added Socialite service provider to config/app.php
# Added redirectToProvider() and handleProviderCallback() to /app/Http/Controllers/Auth/AuthController.php
# Added auth/okta and auth/okta/callback routes to app/Http/routes.php

…but when I pointed the browser at http://tequila-demo.dev/auth/okta I got an error:

InvalidArgumentException in Manager.php line 90:
Driver [okta] not supported.

And I was stumped.

Then I found this issue which gave me the hint to add the following to the boot() function in app/Providers/AppServiceProvider.php (with some tweaking based on socialite-okta/src/SocialiteManager.php).

Socialite::extend('okta', function ($app) {
$config = $app['config']['services.okta'];
$provider = Socialite::buildProvider('Tequilarapido\Okta\OktaProvider', $config);
$provider->setOktaUrl($config['url']);
return $provider;
});

And lo and behold, once we set up the app in Okta and configured everything in the .env file, it works perfectly.

You can re-live the excitement in the commit history of the git repository, if you’ve a mind to do so.

Laravel Socialite driver not supported

New Laravel app

Note – this post is a quick reminder for myself on the steps needed to get a new Laravel app up and running quickly on my Mac dev box, which has Valet set up on my Code directory.

If this post helps someone else, that’s great – but it is not intended for anyone else but me.

  1. In the Terminal window, do cd Code and then laravel new foobar to create the project
  2. Wait while Composer does its thing, downloading and installing a ton of stuff
  3. Type cd foobar to go in to the new project’s directory
  4. Then do git init and git add . and git commit -m "initial commit" to set up the Git repo
  5. In MySQLWorkbench, open Local Mac and create a new schema named foobar with default collation set to utf8-default collation
  6. In the .env file (Not the .env.example file) set APP_NAME = Foobar and DB_DATABASE=foobar and then copy the username and password from another working project.
  7. Back in the Terminal, do artisan migrate and you’re done.
New Laravel app

Raspberry Pi DLNA

I’ve got DNLA working on my Pi, but the minidlna service isn’t starting at boot.

I’ve been typing the command sudo service minidlna restart after each reboot, but I don’t want to have to remember to do that every time the Pi restarts for some reason. Typing sudo service minidlna force-reload is also helpful when you’ve added a new file to the server and want it to be available. Perhaps I’ll stick that in a regular cron job or something.

I found this page which suggested that I sudo apt-get install rcconf and sudo rcconf but rcconf said that the minidlna service is already set to run on startup … which isn’t happening. Every time I reboot, sudo service --status-all says minidlna isn’t running (and, more importantly, I can’t connect from VLC).

I’ve added service minidlna restart to /etc/rc.local but the service still doesn’t start on boot. And when I did update-rc.d sudo service minidlna restart it said using dependency based boot sequencing … which I don’t really understand but it seems to suggest that this ain’t going to work. 🙂

Which is weird, because sudo /etc/init.d/minidlna start works fine to start the service.

So Plan B was to do sudo crontab -e and stick @reboot service minidlna restart in it … still no dice.

I’ll take another look in the morning…

[Edit] This page suggests that update-rc.d minidlna defaults (or perhaps sudo update-rc.d minidlna defaults) might work … so I’ve done that. Let’s see if miniDLNA comes back after the next reboot.

Raspberry Pi DLNA

Cannot Remove ondrej-php

Sometimes when trying to do a vagrant provision I get an error message cannot remove '/etc/apt/sources.list.d/ondrej-php-*'

When this happens, I need to comment out the line config.vm.provision :shell, :inline => "sudo rm /etc/apt/sources.list.d/ondrej-php-*" in C:\Vagrant\[my-vagrant-box]\scripts\homestead.rb (by putting a # in front of it), then run vagrant provision, then un-comment that line again.

Cannot Remove ondrej-php

A Journey from Oracle to MS SQL Server

The Background

I have an Oracle 11g database. Or at least, it’s not mine – I’m not a DBA – but I have query-only access to view the data.

And I need it in a MS SQL Server database. I’ve got SQL Server 2014 Developer Edition.

There are a bunch of ways to copy tables and/or data from one to the other, but the one that seemed most sensible was Microsoft’s SQL Server Migration Assistant for Oracle (or SSMA, to its friends).

I needed to do some tweaking to connect to my local MS SQL database (from memory, I needed to start the SQL Server Browser service in the SQL Server Services section of the  SQL Server Configuration Manager Utility). But that was (comparatively) simple.

The Problem

The real fun started when I tried to connect to the Oracle database. Which I have regular user access to. I can see all the tables, but I’m not a DBA.

And some very clever person discovered that SSMA needs to read from the SYS.MLOG$ table, which regular users can’t see. Certainly I can’t. The suggestion was to simply

grant select on sys.mlog$ to MyUser

…which would probably work, but I don’t have permission to grant access to anyone.

The Workaround – Part 1

So what to do? The SSMA tool wants to see the SYS.MLOG$ table, and I can’t see it, nor can I give myself permission to see it. One thing I could do, though, was create a different table, with the same fields, and hopefully re-direct SSMA to look at that. Sounds easy, no?

The first step was fairly simple. I created a new table in the Oracle database called MYNEWMLOG (a nine-character title – you’ll see why in a moment). It has to have the same fields as the real SYS.MLOG$ table, which I found on this page but have listed here for posterity:

FLAG - Integer
LOG - String
MASTER - String
MOWNER - String
MTIME - Date
OLDEST - Date
OLDEST_NE - Date
OLDEST_OI - Date
OLDEST_PK - Date
OLDEST_SE - Date
OSCN - Integer
TEMP_LOG - String
TRIG - Integer
YOUNGEST - Date
YSCN - String

So now we have a table that we can access, that is a clone of SYS.MLOG$ (though without any data), that SSMA can look at. All we need to do now is tell SSMA to look at it.

The Workaround – Part 2

OK. So this is the bit that’s a bit … well, dodgy. I searched for the SYS.MLOG$ query that David Baxter Browne mentioned, and eventually found it in Program Files (x86)\Microsoft SQL Server Migration Assistant for Oracle\bin\Microsoft.SSMA.Framework.Oracle.Generic.dll.

Yep. The query is embedded in a DLL.

So of course that’s the end of the road, for anyone who wants to remain on the right side of the license agreement. In theory, you could (I expect) download a hex editor and edit the DLL file, and replace the nine-character Unicode string “SYS.MLOG$” with the nine-character Unicode string “MYNEWMLOG” wherever it appears. In theory. The strings are the same length so it wouldn’t change the length of the DLL, which is probably a good thing.

And provided you did that carefully, you could (I imagine) probably use the SSMA tool to copy the schema from your old Oracle database to your new MS SQL database.

In theory. I expect. But if course I wouldn’t know for sure.

A Journey from Oracle to MS SQL Server