2016-Dec-01: Why Won’t it Save??

<– Back to all “Work Diary” entries

Ran into two fun issues with the FW/1 ORM today.

(For the uninitiated, FW/1 is an Adobe Coldfusion MVC framework.)

Issue 1 – FK Relationship Would Not Persist

Turns out, the FW/1 ORM does not handle one-to-one relationships very well when the foreign key is on the entity not most often used to access the relationship.

For example, let’s say that we have a Team object and a CustomerBranding object. Adding the team_id foreign key to the CustomerBranding object resulted in the relationship not saving in Base.cfc (part of FW/1, I think?) because the ORM was looking for the fkcolumn value in the Team entity file but it was instead in the CustomerBranding entity file.

This was really the fault of Base.cfc – it was using the fkcolumn without checking that the entity had the column, so I added a structKeyExists check and everything worked.

Yay FW/1 ORM…

Issue 2 – Unable to Access Saved Entity

Once the above dragon had been slain, I had to figure out why the now-saving Team entity would error when branding was first added to it. I created a new CustomerBranding entity, set the Team, and saved. Done. But then the CustomerBranding object kept saving to the DB with a school/org attached to it, which then would cause an error due to a uniqueness constraint on that column.

(I honestly can’t remember why the school/org wasn’t getting set at this step of the process…but I’m sure there was a reason…)

Turns out the fix was to create the CustomerBranding object as above, save it to the DB, flush the ORM, and then manually go in and set the school/org to null, and then save and flush again. Quite expensive, but this will only be run once for each team when they first turn on branding, plus its an internal thing at this point, so not going to lose any sleep over a few extra milliseconds.

Ahh Coldfusion… 😒

Key Takeaways

  • Dumping objects to the screen and inspecting them is your friend. Do it early and do it often.
  • Don’t be afraid to change code and play around with things. With git, you’re only one git checkout from a clean slate.
  • Bring in help only as a last resort. It takes others a good 30 minutes to get up to speed on a difficult bug like this. The upside of this is that explaining the situation can often lead to new insights as you look at the problem with new eyes, but definitely don’t jump straight to this. I’d only recommend after 15-20 minutes of playing with it yourself and not getting anywhere.

<– Back to all “Work Diary” entries