Colin Law wrote in post #968413:
Just another quick question if you don't mind.
I'm trying to manually append a SafetyOfficer to the Timesheet with the Rails console:
Incident.first.timesheet.safety_officer << SafetyOfficer.last
NoMethodError: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.<<
I searching for a solution but can't find anything. Do you know what this error message means? All the fields in SafetyOfficer.last are correct, and 'timesheet_id' is nil.
Just another quick question if you don't mind.
I'm trying to manually append a SafetyOfficer to the Timesheet with the Rails console:
Incident.first.timesheet.safety_officer<< SafetyOfficer.last
This is pulling just the first record found of incident so its an object of Incident with an associated object of timesheet with an associate object of security_officer. You need to have an array for this as you are appending an object to an array.
It looks like an incident has 1 time sheet and that a timesheet should have many security officers, so that should be plural.
Incident.first.timesheet.safety_officers << SafetyOfficer.last
You will want to make sure that you are using a join for this and it would be best to have this action in the join table's create action, IMHO at least.
If this is not what you are looking to then maybe some more detail as to what you are trying to accomplish would help.
Jesse wrote in post #968644:
Are your associations the same for FireFighter and SafteyOfficer?
Jesse wrote in post #968651:
Theres the difference.
Incident.first.timesheet.fire_fighters is an array of firefighter objects and thus you can append a new member to it.
Incident.first.timesheet.safety_officer is a direct possession of a safety_officer object, so you are not appending a safety_officer to it, but rather adding its ID to a safety_officer_id column.
So array << new_array_member would not work in this case.
If there i to be only 1 safety_officer or a timesheet then the way you would want to create the association is to have a form for the timesheet in question that has the value of the safety_officer_id attribute set to the id of the safety_officer you want to associate to the time sheet. Submit and let rails do the work. It should glean that you are trying to update just the 1 attribute for that timesheet and trigger an update action on it.
Jesse wrote in post #968656:
Finne Jager wrote in post #968650:
Jesse wrote in post #968644:
Just another quick question if you don't mind.
Please start a new thread for a new issue in the future.
[...]
The Timesheet only has_one SafetyOfficer: -------------------------- class Timesheet < ActiveRecord::Base belongs_to :incident
has_one :command_officer has_one :fire_chief has_many :fire_fighters has_one :safety_officer has_many :emts
... and about 10 more ---------------------------
Can one safety officer appear on multiple timesheets? If so, then you'll want all those has_one associations to be belongs_to instead. Please review the difference between the two. Likewise, has_many :fire_fighters should probably be has_and_belongs_to_many, for the same reason.
Best,
Marnen Laibow-Koser wrote in post #968664:
Finne Jager wrote in post #968650:
Jesse wrote in post #968644:
Just another quick question if you don't mind.
Please start a new thread for a new issue in the future.
[...]
The Timesheet only has_one SafetyOfficer: -------------------------- class Timesheet < ActiveRecord::Base belongs_to :incident
has_one :command_officer has_one :fire_chief has_many :fire_fighters has_one :safety_officer has_many :emts
... and about 10 more ---------------------------
Can one safety officer appear on multiple timesheets? If so, then you'll want all those has_one associations to be belongs_to instead. Please review the difference between the two. Likewise, has_many :fire_fighters should probably be has_and_belongs_to_many, for the same reason.
I understand what you mean with that, the way I have it set up is that the personnel is unique for each time sheet. The FireChief model for example also has fields that contain 'time spent on scene' and 'hourly rate' etc.
Finne Jager wrote in post #968666:
Marnen Laibow-Koser wrote in post #968664:
Finne Jager wrote in post #968650:
Jesse wrote in post #968644:
Just another quick question if you don't mind.
Please start a new thread for a new issue in the future.
Ok, will do!
[...]
The Timesheet only has_one SafetyOfficer: -------------------------- class Timesheet < ActiveRecord::Base belongs_to :incident
has_one :command_officer has_one :fire_chief has_many :fire_fighters has_one :safety_officer has_many :emts
... and about 10 more ---------------------------
Can one safety officer appear on multiple timesheets? If so, then you'll want all those has_one associations to be belongs_to instead. Please review the difference between the two. Likewise, has_many :fire_fighters should probably be has_and_belongs_to_many, for the same reason.
I understand what you mean with that. The way I have it set up is that the personnel is unique for each time sheet. The FireChief model for example also has fields that contain 'time spent on scene' and 'hourly rate' etc.
Wait, so if Fire Chief Bob responds to three incidents, he's got three FireChief records?
If so, that's very poor data modeling. What you want to do in that case is set up a join model -- call it Attendance or something -- associated both with the timesheet and the person. This would contain information unique to *that combination*, so there would be one Attendance record for Bob at today's car accident, a second for Bob at tomorrow's train wreck, and so on.
If this is foreign to you, please go read about database normalization. The Wikipedia articles are excellent.
Further thoughts: * FireChief, SafetyOfficer, and so on may not have to be separate tables or classes. * Attendance will probably do for any type of personnel, so you probably wouldn't need separate SafetyOfficerAttendance, FireChiefAttendance, and so on.
Best,
I understand what you mean with that. The way I have it set up is that the personnel is unique for each time sheet. The FireChief model for example also has fields that contain 'time spent on scene' and 'hourly rate' etc.
Wait, so if Fire Chief Bob responds to three incidents, he's got three FireChief records?
If so, that's very poor data modeling. What you want to do in that case is set up a join model -- call it Attendance or something -- associated both with the timesheet and the person. This would contain information unique to *that combination*, so there would be one Attendance record for Bob at today's car accident, a second for Bob at tomorrow's train wreck, and so on.
If this is foreign to you, please go read about database normalization. The Wikipedia articles are excellent.
Further thoughts: * FireChief, SafetyOfficer, and so on may not have to be separate tables or classes. * Attendance will probably do for any type of personnel, so you probably wouldn't need separate SafetyOfficerAttendance, FireChiefAttendance, and so on.
This system will be used by multiple Fire Departments to submit data from their incident/time sheets from the scene of an accident.
If I were to use a join model like that, does that mean that a Fire Department has to initially enter all their personnel into the database, then select per incident which person responded, like a checklist? They often use 'outside' teams as well, so if they use different people all the time, wouldn't that checklist become very long?
Finne Jager wrote in post #968681: [...]
This system will be used by multiple Fire Departments to submit data from their incident/time sheets from the scene of an accident.
If I were to use a join model like that, does that mean that a Fire Department has to initially enter all their personnel into the database,
Not necessarily. You could provide an interface to add new personnel on the fly. It wouldn't have to be done in advance. Anyway, this is a user interface issue and needn't have anything to do with the data modeling.
then select per incident which person responded, like a checklist? They often use 'outside' teams as well, so if they use different people all the time, wouldn't that checklist become very long?
That's a user interface issue. There are good ways of taming that sort of thing (say, by autocompleting a partially entered name), but they're beyond the scope of the current data modeling discussion.
You're thinking about UI and implementation together. That's usually a bad thing. You don't want a UI that exposes irrelevant implementation details, and you don't want an implementation that is tied to one UI. Part of the reason we decouple things is so that we can make interface and implementation completely independent.
Best,
You're thinking about UI and implementation together. That's usually a bad thing. You don't want a UI that exposes irrelevant implementation details, and you don't want an implementation that is tied to one UI. Part of the reason we decouple things is so that we can make interface and implementation completely independent.
I understand, it looks like I have some remodeling to do. 
I was indeed thinking too much from a UI point of view. I'm fairly new
to database modeling so I will check out the resources you mentioned.