Adding Columns

[Midnight Modding]

Just curious about an opinion from someone from IPS on a third party app adding columns to the members table. I have some people suggesting to only add to members if it's a few columns, some saying never do it, some saying always do it as it's no big deal. I'm talking anywhere from 10-20 columns.

I'm not trying to get anyone called "wrong". Just seeing if someone feels it's acceptable to add however many to the members table. Many apps do add it there and it's sure preferable to me, personally, because then you know every member already has a row without having to constantly do a try/catch and create their row. Plus then I wouldn't have to move their data for 3.x users.

[KT Walrus]

I'm not from IPS, but I would think it is best to create your own members table to contain the app specific columns. If for no other reason than when your third party app is installed, it doesn't have to alter the core_members table. For some IPS4 installations, the members table may be quite large and adding columns (and maybe indexes) might take a while. Much better to have each app have its own app_members table where the primary key is the member_id.

As for having to "constantly do a try/catch and create their row", you could extend the Members active record to do a LEFT JOIN on your app_members table to load the app specific columns when the member's active record is loaded. Or, the active record for you app_members table could have a method that loads the app_members rows and if none present, creates a default row. No need to have the callers have to try/catch and create. The called methods should do that if you app requires a default row for each member that uses your app.

[Midnight Modding]

Well, for now I do have my own table added. It's just so convenient the other way, so figured I'd ask. Also on this particular custom version, you can't really do anything without the row (ie it requires you to fill some info out, which gets added to that row, before you can use much of anything in the app), so when it comes to updating the row in other areas it doesn't really need a try/catch, because it's known they have the row by then.

I started to do as someone on here suggested, make my own class that extends the members class and join it that way (where it wouldn't be joined outside my app, unnecessarily), but for the logged in member that really does no good because their core_members row would already be in memory, so I might as well select only my table's row with another query at that point. And for a non-logged-in member I might as well just do a query myself and use constructFromData for Member and my class.

[Midnight Modding]

Btw, just to give the other side on this, someone said well IPS does it with their addon apps, so why not us? The altering/removing would apply to those apps, also, but they do it.

I'm not arguing that it is right or wrong. That is why I asked here, just to get some more opinions.

[bfarber]

You should always create your own table to store the data.

(We should too for first party apps, but the adjustments needed during upgrades and the time we'd spend making these changes after doing it a different way for so long means this is low-priority for us to do internally...sometimes it's hard to justify changing something to do it "the right way" when we won't really actually realize any changes other than a sense of pride for doing something "better"  ).

 

[Midnight Modding]

Thanks. I keep running into a lot of situations where I am having to decide if doing it a better way is worth it or not. I most likely will do it with the separate table, but just hate to have to move so much data around during the update routine.

Probably what I should also do is use the member sync to insert a row for new members, as well, so then I'd not even have to ever check to see if they have the row or not, as existing ones would be done during the upgrade routine, as well.

I forgot just how large of an app this is, which I am updating. I'm just constantly running into situations where I have to decide whether or not something is worth the extra time changing. An idea of how big it is.... it has 30-40 notification keys in the custom version. (edit: a note on that... in 3.x I did them within 3 keys. Maybe should have left it that way. More control for members if they are all separate, though).