Background, I’m creating a app to keep track of motorcycle rides and who came along. The UserID is called ‘Rider’. Riders are entered by myself and when we have gone on a ‘Ride’ I want to select the ‘Riders’ that went on the ‘Ride’. I need to supply all my ‘Riders’ to the “New” ‘Ride’ View for selection. Furthermore, I want to create a row in a different Table called ‘Rides’ for each ‘Ride’ to record the miles and other data for that ‘Rider’ on the ‘Ride’ for later reporting etc. The ‘Rides’ table ties the ‘Ride’ and ‘Rider’ together for later access. I’m sure I could figure this out myself given time but Rails has so many elegant constructs available and I’m pretty new to Rails so I could use some help with direction. It’s a pretty simple concept with powerful possibilities to grow. There are also locking and threading needs will envolve. Any constructive help would be much appreciated. I am a retired Software Engineer in the American Legion Riders enjoying riding and still like developing software. I was really a Firmware Developer but like the Rails Web Development System and want to learn it. The end report will use all the same ‘Rides’ destination and date for each ‘Rider’ and produce the ‘Ride’ entry. I will be able to do the same for a ‘Rider’ and get their total mile for a given interval and ‘Ride’
Sounds like you probably want at least three models total – as you’ve indicated, one for the users who are in “Rider”, and one to indicate the rides, so “Ride”, and also because one rider could go on many rides, plus one ride can have multiple riders, then to tie them together an associative table. The model for this could be called “RiderRide” (or “RideRider” … but I’ll go with the former.)
So things looks like this, where the arrow heads point towards where foreign keys exist:
Rider --> RiderRide <-- Ride
In Ride could be such things as start time, miles, end time, origin, and destination. In Rider could be name and phone number.
Here’s a video overview of building this kind of thing out using the Brick gem:
And here’s the project out on Github.
Lorin, good stuff! Looked at your Brick gem utility. The YouTube Video really covered what I was thinking, I was looking at the associations in the Active Record Models which is what I have been looking at learning. The video host was really going fast so I stopped the video to study the concepts, not sure if I’m ready to use Brick yet I like to really understand the basics before using the automation. Kinda of like writing the code myself vs using a IDE to write code, takes longer but I really know whats there. This is a big help and you validated my direction and gave me a good name for my third table to tie the Rides and Riders. Thank you again for your input.
Hi Mike, I haven’t watched the video, but Lorin put you on the right track with two main models (Ride and Rider) and a join table/model. You want to keep your models and tables named similarly to maximize the benefits of Rails. Your initial thought of have both a Ride and Rides model where the latter is the join is a bad plan - the similar names will lead to A LOT of confusion and issues with pluralization. Lorin’s proposed RiderRide name for the join is much better, it is convention and will help you avoid confusion down the road. (sorry bad pun)
But beyond naming, you have the right basic idea. You don’t need the Brick gem or any other add-ons to do this. Building an association between Rides and Riders is very core, basic, Rails functionality. I’d recommend starting with the Rails Guides. You want a has_many: through: association as described here.
Best of luck!
I had built Brick after teaching a bunch of Rails bootcamp courses – designed to show folks the “Rails” way of things really quickly. It is good to learn how to do it 100% on your own though!