Change ORM relationship model

dev support
1

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.

2

Hi,

just a general remark. If you are fighting with ORM there is a good introduction, check out http://www.coldfusionormbook.com/.

Have as well a look on GitHub - coldbox-modules/quick: A ColdBox ORM Engine (I haven’t tried myself yet, but it receives some good community feedback)

3

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.

4

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