On 12/15/10 12:40 PM, Finne J. wrote:
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.
On 14 December 2010 18:44, Finne J. [email protected] wrote:
Ok, thanks for the development log tip! I wasn’t aware of it.
I now use the incident_id to set @timesheet like this:
@timesheet = Incident.find(params[:incident_id]).timesheet
And it looks like it’s working!
Great. Do have a go with ruby-debug too. You should not need it
often but sometimes when you just cannot understand what is going on
then it is invaluable.
Colin
Jesse wrote in post #968644:
On 12/15/10 12:40 PM, Finne J. wrote:
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.
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
The only thing I want to do is to append the SafetyOfficer.last to the
Timesheet of Incident.first .
I did this earlier today with a FireFighter and it worked fine. I don’t
know why it’s not accepting the SafetyOfficer if I’m doing it the same
way.
I also tried: Timesheet.last << SafetyOfficer.last
Which returned ‘undefined method <<’
Jesse wrote in post #968651:
On 12/15/10 1:19 PM, Finne J. wrote:
object of security_officer. You need to have an array for this as you
has_one :safety_officer
Are your associations the same for FireFighter and SafteyOfficer?
Timesheet
has_many :fire_fighters
has_one :safety_officer
And both FireFighter and SafetyOfficer belongs_to :timesheet
The models both have timesheet_id fields as well.
On 12/15/10 1:19 PM, Finne J. wrote:
object of security_officer. You need to have an array for this as you
has_one :safety_officer
Are your associations the same for FireFighter and SafteyOfficer?
On 12/15/10 1:27 PM, Finne J. wrote:
And both FireFighter and SafetyOfficer belongs_to :timesheet
The models both have timesheet_id fields as well.
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:
On 12/15/10 1:27 PM, Finne J. wrote:
And both FireFighter and SafetyOfficer belongs_to :timesheet
The models both have timesheet_id fields as well.
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.
I understand what I’m doing wrong. I don’t have to append the
SafetyOfficer at all, I just need to SET it because there can be only
one SafetyOfficer.
Incident.first.timesheet.safety_officer = SafetyOfficer.last
Marnen Laibow-Koser wrote in post #968664:
Finne J. wrote in post #968650:
Jesse wrote in post #968644:
On 12/15/10 12:40 PM, Finne J. wrote:
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.
Finne J. wrote in post #968650:
Jesse wrote in post #968644:
On 12/15/10 12:40 PM, Finne J. wrote:
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
http://www.marnen.org
[email protected]
Finne J. wrote in post #968666:
Marnen Laibow-Koser wrote in post #968664:
Finne J. wrote in post #968650:
Jesse wrote in post #968644:
On 12/15/10 12:40 PM, Finne J. wrote:
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,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
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?
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.
Finne J. 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,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]