Category: ORM

Cookies and Treats! – #NCDEVCON – Live Blog 2


NCDevCon North Carolina’s Premier Web & Mobile Conference

The term “Cookies” in development of course has multiple meanings.  But at #NCDECVON during the break sponsored by Strongloop, cookies were plenty and sweet!  Delicious cookie sandwiches filled with coma inducing filling.  Sorry for those speaking afterward….I forsee a lot of snoring!  Don’t take it personally!

Another “treat” was Raymond Camden’s talk on APIs….well…except he called an audible. Instead he tested out another talk he is working on about changes in programming.  Nostalgic man!  Nostalgic!  He even showed a program printed in “Family Computing” magazine in the early 80’s I believe.  Man I felt old!  I remember putting the program into my Apple II compat. computer (Franklin Ace 1000) and watching it works. Thanks for making me feel old Raymond!  Seriously!  Funny and inspiring talk though.

I also caught Matthew Eash’s talk on Node.js, in particular the Express framework.  Still can’t say I fully understand it, but it definitely started to make sense to me.  Pretty flipping cool for sure!

Ok, back to business. Hope the caffeine kicked in.  Getting ready for Less Hate, More Love With Coldfusion ORM  by Masha Edelen.  Met her earlier and am looking forward to hearing talk on the topic. Let you know how it goes!

OhRM! Why Aren’t You Updating?

One of the great (and probably terrible) things about having so much to learn in the development world is that I often find myself trying to learn several things at the same time.  For example, late last week I began playing with the jQGrid plug-in. But I had to build back-end support for it, so I did that in ColdBox (which I also have been playing with).

Things went great on pulling the data and pushing it to the plug-in.  But things got more complicated when I had to build the back-end methods for processing the updates from jQGrid.  Building the SQL statements was a challenge. In the back of my mind I heard a voice screaming “ORM” (Object Relational Mapping), but while I have flirted with ORM (by that I mean watched one or two online presentations about it), I hadn’t taken the plunge.  So did I really want to add a third variable to this R&D?  I resisted as long as I could…but going non-ORM with this was getting ridiculous, especially since I was building a back-end to handle just about any table we need it to.  No doubt about it. ORM was the way to go!

So I took the plunge.  First hurdle….how can I use ORM on existing tables without running the risk of it modifying those table structures. A quick Google search brought me the answer (on Ben Nadel’s Blog no less…..a lot of CF developers need to buy him drinks for the amount of time his posts save).  Simply adding:

this.ormSettings = { dbCreate = “none”}

to the application.cfc file solves that problem.  It prevents ORM from making structure changes.  Great!  Now I can move on!

Fetching data with ORM was a breeze!  It also allowed me to eliminate several private methods in my CFC.  Sweet!  And look.  Updating information is as easy as loading an entity, changing its properties, and saving it back out.  Perfect….except….the data in the DB table didn’t change.

What was I doing wrong? I scoured numerous blog posts on ORM, tried everything from saving, to not saving, to flushing….no joy! I spent a good 6 hours or more trying numerous things and cursing this wretched beast known as ORM!!!!

Then I found the problem.  Because I was building this back-end to handle any table we need it to, having to know the names of the setters and getters was troublesome.  In ORM, those are created for you and are named based on the property name. For instance, I have a title field. So the setter is setTitle() and the getter is getTitle(). Simple enough, but I won’t know what fields my entity has until run-time since it will depend on what entity is being requested.  As an aside, would it not make more sense to autogenerate a function called “setProperty” and pass it the property name and value, and a function called “getProperty” and pass it the property name and value, than to generate two functions for each and every property in the entity?  Would love to know why its done that way.

However, one way around this I saw was just to set the property directly on the entity. So if my entity’s name was oTest, I could set the title by saying “oTest.title = “This is a test”.   Basically what is happening is, ColdFusion implicitly calls the correct setter based on the property name…but only  if you put the statement

this.invokeImplicitAccessor = true;

into your application.cfc.  What a great solution!

But what confused me is I had done all of that and still it was not updating my DB.  Hours went by. Finally I tried a test using the setter directly. The database changed.  Looking at the dump of my entity showed it having all the properties I set and a property called “properties” that also had each one of the properties but with the values pulled from the DB. That should have been my clue.  The invokeImplictAccessor setting was failing. It was not giving me an error. It just wasn’t working.   The culprit….support for invokeImplicitAccessor started in CF10. I am developing on CF9.  Grrrr! Not giving up on ORM…just have to go find a workaround now. Suggestions welcomed.

© 2018 Script Van Winkle

Theme by Anders NorenUp ↑