-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Karl Erik Levik edited this page Oct 3, 2018
·
3 revisions
Here are the exact columns we populate in the Diamond ISPyB database and explanations for most of the columns.
- proposalCode: a varchar (string) such as 'mx', 'cm', 'in', etcetera
- proposalNumber: an integer (although this is a varchar (string) column
- title: the title of the proposal, e.g. 'X-ray diffraction study of ....'
- externalId: This is a reference back to the particular row in the user office database table where this proposal originated. At Diamond our user office database uses UUIDs (e.g. 123e4567-e89b-12d3-a456-426655440000). The data type of the column is binary(16) for optimal storage. This column is not mandatory and not used by SynchWeb.
- personId: This is a reference to a row in the Person table. I think this person is meant to be the Principal Investigator of the proposal. This is a mandatory column. At Diamond we store the PI elsewhere, so we don't really bother with this column, and only "fake" populate it with a '1' to point to the first person who happens to be in the Person table.
- blTimeStamp: This is a timestamp that shows when the table was last updated. If left empty on creation, it will default to the current time.
This is the "visit" table, though "session" is a better term these days. All DataCollections and DataCollectionGroups refers back to this table.
- proposalId: A reference back to the proposal it belongs to.
- externalId: similar as for Proposal.externalId
- beamlineName: e.g. "i03" or "b24"
- comments:
- startDate: Although it says date, this actually holds the exact date and time for when the session starts. The data type is datetime.
- endDate: exact end date and time for the session
- visit_number: The number for this session, which is unique within the proposal. This is the tail end of the visit name, which is made up of proposalCode, proposalNumber and visit_number. E.g.: mx12345-16. (Here, 16 is the visit_number.)
- beamLineOperator: This is the local contact for this session. The data type is varchar (max. 45 chars).
- scheduled: Boolean. Not mandatory. Indicates whether this is a special "queued" (0) or regular scheduled (1) session.
This is basically a table with the users.
- externalId: similar as for the column with the same name in BLSession and Proposal
- login: this is the user name used when logging in to the application
- title: e.g. Dr, Ms, Mrs, Mr, ...
- givenName: e.g. James
- familyName: e.g. Bond
This table says which sessions the persons are on.
- sessionId: a reference to the session row this belongs to. Mandatory.
- personId: a reference to the person row. Mandatory.
- role: Must be one of these values: 'Local Contact','Local Contact 2','Staff','Team Leader','Co-Investigator','Principal Investigator','Alternate Contact','Data Access','Team Member'
- remote: Boolean. Indicates whether the user is remote only (1) or comes in person to the beamline (0).
This table says which proposals the persons are on. This is not used by SynchWeb.
This says something about what kind of session it is. A session can in principle be of multiple types.
- sessionId: a reference to the session row. Mandatory.
- typeName: a varchar. Could be e.g. 'In situ', 'Containment Level 2', 'Containment Level 3', 'Compulsorily Remote', ...
Although it's called 'Protein', we use this for other molecules as well such as RNA, DNA and small molecules. Note that the actual instance of the sample is stored in different tables which refer back to this one.
- externalId: similar to columns with the same name in the other tables
- proposalId: a reference to the proposal row it belongs to. Mandatory.
- name: The full name of the molecule.
- acronym: The acronym used.
- proteinType: varchar. I don't think this is used by SynchWeb. We just "fake" populate this with a string to say the protein originated in UAS, i.e. was not created in SynchWeb.