Curious what the MemberProfile model would look like if it were a PORO and not inheriting from AR as suggested. It could not make use of AR associations in the model, so what would that look like? Thanks for a great episode!

Yes, sorry I meant GuestProfile as a PORO, not MemberProfile, as Ryan states at around 13:40 in the railscast.

It sounds like he's suggesting there would be no AR association between GuestProfile and User, that there would be a null check on profile_id in the users table and if the value was null then the app would generate a PORO in memory to handle Guest related behaviors (validations, methods, etc). But how would that PORO be bound to the relevant User record?

I think I see what he's saying. Completely remove the polymorphic association, User and MemberProfile have a simple has_one/belongs_to association, guests are stored in Users table as well, but they have no MemberProfile so the profile_id foreign key in Users is null for guests and we conditionally build a PORO for guests when a null profile_id is found.

I use quite STI and polymorphism liberally, because I have sets of classes with exactly the same columns. Even so I learned a lot from this episode. I especially like the way you discussed the trade-offs between different approaches. Often, the hardest part is knowing the best option. I end up coding it one way, hating it later then refactoring it to another way. This can waste weeks of time if the models are heavily used throughout the application.

I also really like your authentication from scratch. When AuthLogic went through it's unsupported period (Rails 3.0) I was really stuck and really came to value being in control of my core logic. Often we use huge gems because we need 10 lines of code from them, and spend more time figuring out how to wrangle them to fit our needs when coding from scratch is tiny, fast and takes less time (Devise).

I also typically do auth from scratch, but have lost a job possibility based on that. They felt I was a 'lone wolf' for doing my own auth, and were afraid I could not work well with a team (You know, even though I have worked on teams up to almost a hundred people).

Yes, it probably said a lot about the company and was probably a good warning indicator that that might not be the best company in the world to work for.

I wonder if the :dependent => :destroy relationship should be in the user instead of the profile. This would probably only be a concern when transitioning between profiles, but if you want to delete the guest profile before adding the member profile you have to wait until after the user has been updated. On the other hand, if the user is destroyed, chances are you want the profile to be destroyed along with it.