Change ORM relationship model

Hi all,

I’m new to building on Lucee and Coldbox. Just getting up to speed now and I’ve been told this is the place to be!

I’m working on a project at the moment that has existing tables and data. Essentially a Profile table, Directory table, and a table (let’s call ProfileDirectory) that links the two in a many-to-many type of relationship all handled by the ORM in Coldbox. All well and good so far.

Now… I want to extend the functionality so that Profiles listed in a Directory can be a ‘basic’ or ‘premium’ listing. I know how to tackle this from a direct SQL query approach, but the ORM is fairly ingrained in the current project so I need to work with that. My line of thinking is to extend the ProfileDirectory table from 2 columns (which have the IDs of each of the other tables) to include a third column that’ll indicate ‘basic’ or ‘premium’ (this could be a simple INT or Boolean).

Right… My understanding from googling the interwebs, doing this to a many-to-many ORM relationship tends to lead to creating a third data model (for ProfileDirectory), then having a many-to-one and one-to-many between all three,

eg. Profile => m2o => ProfileDirectory => o2m => Directory.

Rather than the existing: Profile => m2m (ProfileDirectory) => Directory.

So… I’m a little unclear on the best approach without direct intervention into the database to modify the existing data, as I see ProfileDirectory table becoming something like: (id, premium, profileID, directoryID).

Perhaps I’m going about this the entirely wrong way??? Any help to implement the above or should I approach it differently?

Thanks in advance and I look forward to connecting further with the community.


just a general remark. If you are fighting with ORM there is a good introduction, check out

Have as well a look on (I haven’t tried myself yet, but it receives some good community feedback)

What you are describing is exactly how I would approach the task. Make sure to backup, but once you change your model and reload you should get the extra fields in ProfileDirectory.

You’re spot-on with the replacement of many-to-many with separate “linking” entities.

You can also take advantage of CF OOP inheritance by using the mappedSuperClass attribute on a persistent CFC, so if you had:

_Profile.cfc has the attributes mappedSuperClass=true in the component definition and contains all properties and functions common to all Profiles
BasicProfile.cfc and PremiumProfile.cfc have the attribute extends="_Profile.cfc" and only contain properties or functions not found on the parent.

1 Like