A battle with racing
I’m still on the Laravel migration. It’s going pretty well, except for last night. Last night I was porting racing.
It was awful.
I didn’t get to bed until something like 4am and my brain seems to have blocked out a sizeable chunk of what actually happened from memory, but during the course of the afternoon I went through problem after problem. Each time I solved one thing some other functionality broke and by the end I didn’t know wtf was going on.
The problem started with my fundamental misunderstanding of the Eloquent
update(). After reading the Laravel documentation I got the impression that
update’s entire purpose is updating specific attributes of a model. You pass an array of attributes, Eloquent updates the table.
Apparently that’s not how it works. When you run
Model::update($propertiesToUpdate) it doesn’t just update those properties - it looks for any dirtying of the model and apparently tries to save everything that may have changed. Unfortunately in my current setup the model also represents a complete instance of a snail that has additional properties set after it is loaded. So as an example…
snail->currentEnergy is not stored in the database, but calculated when the model is loaded based on the snail’s current protein, fat, and carb counts. When I tried making neccessary changes to the racing snail post-race to record depletion of these macros I was getting an error about a column not existing. But it wasn’t supposed to exist at all.
I went to Laravel IRC for help. People were very helpful and responsive. It took a while of going in circles. I was getting a little frustrated with the whole situation because it cannot be that difficult to save a fricking change to some specific fricking fields and only those fields in the db through Eloquent. I would have thought it would be at least as simple a process as manually building a query and running mysqli was. In the end we decided that using the query builder was my best bet. So now instead of using
$snail->update($propertiesToUpdate) I use
This works. I do eventually want to go back and change my entire setup to avoid dirtying the model. For now, though, I just want to get this thing back to the state it was in the vanilla PHP version.
Anyway, then there were some other issues with Eloquent relationships, but those were caused by sleepiness more so than any actual bug or source of confusion. Here’s an example of how my Laravel relationships are set up for races and their entries at the moment:
- Race model
- RaceEntry model
This makes it easy to immediately load the entries associated with each race as well as the snails associated with each entry for use during the race. In a similar way, I can easily get a snail’s owner via a
belongsTo relationship. From there it’s just a matter of Eager loading the model associated with the relationship when loading the parent model itself. Or lazy loading it via
$race->load('entries') for example.
Anyway, the races are running now. They’re not done, but they’re now up to the same state as the vanilla PHP version. Up next I want to do a bit of cleanup and then start reimplementing items. This port is taking longer than I thought, but I can see the benefits of using Laravel. I’m finding myself cutting out huge chunks of code I had in the vanilla version that, with the help of Laravel and Eloquent, are just no longer needed. Eloquent makes data retrieval and validation much easier and faster to implement.
Up next I want to do some cleanup and then start on the item reimplementation. Wish me luck.