Jump to content

Member Row


Recommended Posts

Posted

When attaching members for a notification, does it need so many of the members table columns as to warrant me using constructFromData() on a whole row? Or does it only need a few columns like member_id and their notification settings? (I sure hope their notification settings aren't in a whole different table where it would have to do an extra query for each attached member... I'm going to assume it's probably stored in one column in the members table as an encoded array, but I haven't had time to go through files looking.).

The reason this all came up in my mind is because I was debating how important it is to select only the needed columns. But the more I think about it... really why should I do it that way? It seems to me that IPS decided that ease of use outweighs any performance gains from naming the columns to select. Look how often load(), the various WithPermission() methods, and table helpers are used, where they select the whole row automatically. I had thought about making my reusable queries take a parameter for the columns to select, but if these first party examples aren't doing it, it makes me feel like people with more experience than me feel it's not a huge enough deal to always allow for that.

Posted

I feel like really I know what the answer is going to have to be about this specific example. Even if it only uses a few columns, pretty much we are going to have to select the whole members row anyway, because we don't have any idea if you guys will add more features to notifications down the road, which need more columns' data. So there's really no choice, unless we want to keep checking on every release and modifying our code.

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...