From Code to Community: Sponsoring The Perl and Raku Conference 2025 Learn more

NAME

App::Dochazka::REST::Model::Schedhistory - schedule history functions

SYNOPSIS

DESCRIPTION

A description of the schedhistory data model follows.

Schedhistory in the database

Table

Once we know the SID of the schedule we would like to assign to a given employee, it is time to insert a record into the schedhistory table:

CREATE TABLE IF NOT EXISTS schedhistory (
shid serial PRIMARY KEY,
eid integer REFERENCES employees (eid) NOT NULL,
sid integer REFERENCES schedules (sid) NOT NULL,
effective timestamp NOT NULL,
remark text,
stamp json
);

Stored procedures

This table also includes two stored procedures -- sid_at_timestamp and current_schedule -- which will return an employee's schedule as of a given date/time and as of 'now', respectively. For the procedure definitions, see dbinit_Config.pm

See also "When history changes take effect".

Schedhistory in the Perl API

For basic workflow, see t/model/schedule.t.

EXPORTS

This module provides the following exports:

get_schedhistory

METHODS

load_by_eid

Class method. Given an EID, and, optionally, a timestamp, attempt to look it up in the database. Generate a status object: if a schedhistory record is found, it will be in the payload and the code will be 'DISPATCH_RECORDS_FOUND'.

load_by_id

Given a shid, load a single schedhistory record.

load_by_shid

Wrapper for load_by_id

insert

Instance method. Attempts to INSERT a record into the 'Schedhistory' table. Field values are taken from the object. Returns a status object.

update

Instance method. Updates the record. Returns status object.

delete

Instance method. Deletes the record. Returns status object.

get_schedhistory

Takes a PARAMHASH which can have one or more of the properties 'eid', 'nick', and 'tsrange'.

At least one of { 'eid', 'nick' } must be specified. If both are specified, the employee is determined according to 'eid'.

The function returns the history of schedule changes for that employee over the given tsrange, or the entire history if no tsrange is supplied.

The return value will always be an App::CELL::Status object.

Upon success, the payload will be a reference to an array of schedhistory objects. If nothing is found, the array will be empty. If there is a DBI error, the payload will be undefined.

EXAMPLES

In this section, some examples are presented to give an idea of how this module is used.

Sam Wallace joins the firm

Let's say Sam's initial schedule is 09:00-17:00, Monday to Friday. To reflect that, the schedintvls table might contain the following intervals for sid = 9

'[2014-06-02 09:00, 2014-06-02 17:00)'
'[2014-06-03 09:00, 2014-06-03 17:00)'
'[2014-06-04 09:00, 2014-06-04 17:00)'
'[2014-06-05 09:00, 2014-06-05 17:00)'
'[2014-06-06 09:00, 2014-06-06 17:00)'

and the schedhistory table would contain a record like this:

shid 848 (automatically assigned by PostgreSQL)
eid 39 (Sam's Dochazka EID)
sid 9
effective '2014-06-04 00:00'

(This is a straightfoward example.)

Sam goes on night shift

A few months later, Sam gets assigned to the night shift. A new schedhistory record is added:

shid 1215 (automatically assigned by PostgreSQL)
eid 39 (Sam's Dochazka EID)
sid 17 (link to Sam's new weekly work schedule)
effective '2014-11-17 12:00'

And the schedule intervals for sid = 17 could be:

'[2014-06-02 23:00, 2014-06-03 07:00)'
'[2014-06-03 23:00, 2014-06-04 07:00)'
'[2014-06-04 23:00, 2014-06-05 07:00)'
'[2014-06-05 23:00, 2014-06-06 07:00)'
'[2014-06-06 23:00, 2014-06-07 07:00)'

(Remember: the date part in this case designates the day of the week)

AUTHOR

Nathan Cutler, <presnypreklad@gmail.com>