Skip to content

Commit fc0f912

Browse files
LeviCameron1LeviCameron1
committed
Update docs with descriptions of the tables
1 parent 6a0b618 commit fc0f912

4 files changed

Lines changed: 156 additions & 0 deletions

File tree

CageUI/src/documentation/CageUI Instructions.html renamed to CageUI/documentation/CageUI Instructions.html

File renamed without changes.

CageUI/src/documentation/Layout Editor.md renamed to CageUI/documentation/Layout Editor.md

File renamed without changes.

CageUI/src/documentation/Migrating to cageUI cages table.md renamed to CageUI/documentation/Migrating to cageUI cages table.md

File renamed without changes.

‎CageUI/documentation/Tables Structure.md‎

Lines changed: 156 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,156 @@
1+
# Tables Structure
2+
3+
This markdown describes the table structure in the cageUI module, what each table is meant for and how it is used. The
4+
markdown tables listed under each table provide short descriptions on what each column is used for.
5+
6+
## CageUI Schema Tables
7+
8+
These are the tables used by the project within the CageUI Schema.
9+
10+
### Racks
11+
This table represents the racks at the center. Our cages are not removable from racks but they do not have
12+
individual cage ids. Therefore, we have this racks table to act as a wrapper for our cages to determine their
13+
type and default sizes, since all cages in a rack are the same size.
14+
15+
| objectid | room | rackid | rack_type | condition |
16+
|-------------------------|----------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|----------------------------------------------------------------------------------------------------------------|
17+
| Unique ID for the rack. | Room the rack is currently in, This can be null to represent that the rack is currently not in any room. | Id of the rack. This should be unique for the rack type but if you have different id systems for different rack types this allows for that. | Self explanatory this is the rack type. | Condition of the rack (ex. broken). We have three conditions which you'll see later in the ehr_lookups schema. |
18+
19+
### Rack Types
20+
This table represents the different rack types that are available for racks to be assigned. It holds information about the rack.
21+
22+
| displayName | type | Manufacturer | Stationary | length | width | height | size | sqft |
23+
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------|----------------------|-------------------------------------------------|------------------------|-----------------------|------------------------|--------------------------------------------------------------------------------------------------------------|-----------------------|
24+
| Name of the rack type combining several columns into a string so the users have a detailed view of what they are choosing. This is how it is built: {type}-{manufacturer}-{size}-{stationary} | Caging type. This is explained more in the ehr lookups section. | Creators of the rack | Determines if the rack is movable between rooms | Length of cage in rack | Width of cage in rack | Height of cage in rack | Cage size in rack. Our users use this instead of exact sqft to determine if animals can fit inside the cage. | Exact sqft dimensions |
25+
26+
27+
### Cages
28+
This table was created as an alternative to ehr_lookups.cages since for our center we had improper formatting of certain columns
29+
within that table causing issues. With some work you can probably use the labkey provided cages table, but this allows for
30+
greater customization of the cages table. If you do use ehr_lookups.cages you will have to add the missing columns to that table via extensible columns, and ensure
31+
they are updated correctly. This table is a list of all cages at the center.
32+
33+
For length, width and height. The numbers here represent the true value of the cage size. The rack type dimensions provide
34+
a starting default value. Since adding certain modifications changes cage size, that updated size will be reflected here.
35+
36+
| objectid | positionid | Rack | cage_number | length | Width | Height | sqft |
37+
|--------------------|---------------------------------------------------------------------|--------------------------------|-------------------------------------------------|------------------------------------------|-----------------------------------------|------------------------------------------|----------------------------------------|
38+
| Unique ID for cage | position of cage within rack goes left to right from top to bottom. | Which rack the cage belongs to | Modifiable number for the cage within the room. | Length of cage, changed by modifications | Width of cage, changed by modifications | Height of cage, changed by modifications | Sqft of cage, changed by modifications |
39+
40+
41+
### Cage Modifications
42+
List of available modifications that can be placed on cages.
43+
44+
| value | title | direction | type |
45+
|------------------------|-------|-----------------------------------------------|-----------------------|
46+
| Short unique text name | title | Direction the modification can be applied to. | Type of modification. |
47+
48+
The important columns here are mainly direction and type. Two modifications of the same type can not exist on the same
49+
cage mod location. Meaning you can't place two dividers on the same side of the cage. Direction shows where the modification
50+
might be available from. If I have cage 1 above cage 2 then only modifications with a vertical direction can be placed on this side.
51+
Direct directions are placed directly on the cage itself and have no connections to other cages. Our center uses a one modification
52+
limit where you usually can not have multiple modifications on the same cage location with a few exceptions.
53+
One exception is different types, meaning you can have a vertical separator and a vertical attachment on the same location.
54+
We also do not have multiple direct modifications, meaning there is a limit of one direct modification on a cage at once.
55+
56+
### All History
57+
This is the top level history table. It holds a start and end date along with the original history id that is linked to
58+
other tables. It also describes if the room is valid, (WIP, you will have to use this at your own discretion with your own
59+
validation).
60+
61+
| room | history_type | valid | start_date | end_date | historyid |
62+
|------------------|-----------------------------------------------------------|---------------------------------------|--------------------------|-------------------------------------------------------|------------------------------------------------------------------|
63+
| Room for history | Determines if the history is a real room or template room | Determines if the room has any issues | Start date of the layout | end_date of the layout (null if it is current layout) | Unique ID that links to other tables to build a complete history |
64+
65+
### Room History
66+
This is the history table that holds data about the room border and size.
67+
68+
| historyid | scale | border_width | border_length |
69+
|----------------------------|-----------------|---------------------|----------------------|
70+
| historyid from all_history | Room size scale | Width of the border | Length of the border |
71+
72+
### Layout History
73+
This is the history table that holds coordinates of cages or room objects for real rooms. As well as any extra context.
74+
75+
| historyid | cage | object_type | extra_context | x_coord | y_coord |
76+
|----------------------------|-----------------------------|----------------------------------------------------------------------------------------------------------------------------|---------------------------------------------|------------------------------------|------------------------------------|
77+
| historyid from all_history | Real cage within the layout | Type of object that the coords belong to. Since this history contains cages and objects it can be any placeable item type. | Any extra context attached to cages/objects | Global x coordinate of cage/object | Global y coordinate of cage/object |
78+
79+
### Template Layout History
80+
Since templates don't contain real cages the history table is easier to maintain and we can just use ids to maintain the cages/objects. This is why we keep separate histories for both tables.
81+
82+
| historyid | rack_group | group_rotation | rack | cage | object_type | extra_context | x_coord | y_coord |
83+
|----------------------------|-------------------------|-----------------------------------|-------------------------------------------------------|----------------------------------------------------------------|--------------------------------------|------------------------|------------------------------------|------------------------------------|
84+
| historyid from all_history | Rack group for the cage | Rotation of the rack for the cage | rack id for cages rack (not real rack in racks table) | cage number for template layout (not real cage in cages table) | type of object the coords belongs to | Extra context for item | Global x coordinate of cage/object | Global y coordinate of cage/object |
85+
86+
87+
### Rack History
88+
History table for the racks within a layout.
89+
90+
| historyid | objectid | room | condition | Notes |
91+
|----------------------------|----------------------------------|-------------------------------------------------------------------------------------------------------|----------------|----------------------------------------|
92+
| historyid from all_history | Racks object id from racks table | Room for rack, if this is null it means the rack was removed from the room during that history change | Rack condition | Any notes applied to the rack by users |
93+
94+
This table is updated by a trigger script when the racks table is updated, this keeps a history of changes.
95+
### Cage History
96+
History table for the cages within a layout.
97+
98+
| historyid | rack_group | group_rotation | cage | cage_number | length | width | height | sqft |
99+
|----------------------------|------------------------------------|---------------------------|--------------------------------|----------------------|--------|-------|--------|------|
100+
| historyid from all_history | The rack group that the cage is in | Current rotation for cage | cage objectid from cages table | cage number for cage | Length | Width | Height | sqft |
101+
102+
This table is updated by a trigger script when the cages table is updated, this keeps a history of changes.
103+
104+
### Cage Modifications History
105+
106+
| historyid | cage | modid | parent_modid | modification | subid | location |
107+
|----------------------------|--------------------------------|--------------------------------|----------------------------------------------------------------------|------------------------------------------------------|----------------------------------------------|-----------------------------------|
108+
| historyid from all_history | Cage objectid from cages table | Unique id for the modification | This is also a unique id for the modification. Explained more below. | Modification value from the cage_modifications table | subsection id for mod, explained more below. | Location on cage for modification |
109+
110+
For some modifications they are applied to two cages. Consider a divider shared between two cages A and B.
111+
This divider is technically applied to both cages, the right side of A and the left side of B. The modid would be a
112+
unique id for both mods, but if I change the modification from cage A then the parent_modid that appears on the modification
113+
history for cage B would have cage A modid. This allows us to track where the modification was changed from and the original change.
114+
115+
Next to explain is subid. The subid (subsection id) is used for larger cages. Our pen cage template is 8x8 cells; this means
116+
that two 4x4 cell cages can be next to it and each of those cages can have a different modification. In our pens case this means
117+
that each side has two lines in the svg that can have different modifications. The subid determines what subsection has which mod.
118+
A subsection is a line within the svg file that follows the path of left -> right or top -> down. These lines have to be
119+
referenced exactly by id when changing modifications, so the system knows what line to edit when changing mods. Take a look
120+
at the pen svg file to gain an understanding of this.
121+
122+
123+
## EHR Lookups Schema Tables
124+
Below are the tables added to ehr_lookups to provide available options for certain columns within the cageui schema tables.
125+
The values in these tables are also stored as enums for development purposes so ensure that they are in sync for the best results.
126+
127+
### CageUI Condition Codes
128+
Rack status conditions such as operational, damaged, etc
129+
130+
### CageUI Item Types
131+
Available item types that can be placed within a layout. For "Caging" items ensure there is a real and default type.
132+
Description in this lookup refers to the "size" of the caging unit. Since all our caging units are squares this size is the
133+
LxW of cells that the unit occupies on the layout.
134+
135+
### CageUI Modification Directions
136+
Direction that a modification goes between.
137+
138+
Vertical means the mod is applied vertically between two cages.
139+
140+
Horizontal means the mod is applied horizontally between two cages.
141+
142+
Direct means the mod is applied directly on the cage and not between two cages.
143+
144+
145+
### CageUI Modification Locations
146+
Available locations of the modification with respect to cages.
147+
Left, right, top, bottom, direct. Self-explanotory this column is used by the modifications history to determine where
148+
on the cage the modification is located.
149+
150+
### CageUI Modification Types
151+
Type of modification, Attachment or separator. Separators are usually dividers/floors between cages.
152+
Attachments are added onto the cage. Attachments can go between multiple cages, an example of this is CTunnels.
153+
154+
### CageUI Rack Manufacturers
155+
Manufacturers of racks used by rack types table.
156+

0 commit comments

Comments
 (0)