Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><em>I think you are trying to swat a mosquito using a mallet.</em> </p> <p>Here is how I tackled the same problem:</p> <ul> <li><p>I wanted to make sure that each user's authentication (username, password) is stored in the same table. Basically, I had three types of users.</p></li> <li><p>I used Sentry 2 which makes it a breeze to manage the authentication stuff.</p></li> <li><p>Using the default migrations provided by Sentry 2, I added a column 'role' to the 'users' table - which differentiates the 3 types of users.</p></li> <li><p>For each user type, I created a table with specific fields.</p></li> <li><p>When the user authenticated, I would grab their 'role' from the 'users' table, run a few if statements and know which view to serve them.</p></li> </ul> <p><em>And the mosquito was completely dead.</em></p> <p><strong>Onto yours:</strong></p> <ul> <li><p>Basically, both our approaches are the same - since each user type has a separate table for fields they don't all share (except first name, last name, email, password, last login etc).</p></li> <li><p>Your approach will allow a user to belong to the three entities - which is logically not correct. Mine won't - which is logically...</p></li> <li><p>You are afraid of 'polymorphic issues' but I don't think we have a lot to deal with here. All we would perhaps do is define in our models that a coach, for example, <code>belongsTo</code> a user. And a user <code>hasOne</code> coach. </p></li> <li><p>But in reality, we don't even need to define the relationships. Because at authentication, we need to run if statements anyway. So, using the user object returned from authentication, we will know two things: which table to then go to for user-type-sepecific information and which view to serve to the authenticated user.</p></li> </ul> <p><em>Don't be afraid, son</em></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload