--- last_review: "2025-01-01" last_reviewer: "-" documented_code: [ ] --- ```{tags} explanation, administrator ``` # Record :::{note} This page has been migrated from the old documentation, and has not yet been fully revised. There might be inconsistencies or errors when using with current LinkAhead versions. ::: % TODO: Issue: https://gitlab.indiscale.com/caosdb/src/linkahead-docs/-/issues/90 % TODO: - Name seems to fit badly with content: Looking at RecordType doc, this might have at some % TODO: point included general explanation of Records? % TODO: - This content is likely needed in explanation, but the doc is written as reference. Decide % TODO: which is the better format and rewrite. % TODO: - Change formatting to be more in line with newer documents % TODO: - This has some duplication with the other Role documents % TODO: Old comments: % TODO: - This specification is outdated. It is included to serve as a starting point for a more % TODO: up-to-date description of the `Record` entity. ## GET records HTTP-GET-requests are to be sent to `http://${host}:${port}/mpidsserver/Record/...`. Default port is 8123. ### Get single record `GET http://${host}:${port}/mpidsserver/Record/1` returns in case of success: 100111327 Here comes the explanation 2010-01-20 20:15:00.0 If a requested record didn't exist, it returns: ### Get multiple records `GET http://${host}:${port}/mpidsserver/Record/1&2` returns in case of success: 100111327 Here comes the explanation 2010-01-20 20:15:00.0 1000.0 Same behavior as above if one of these didn't exist. ## POST records The POST-requests are to be sent to `http://${host}:${port}/mpidsserver/Record`. Default port is 8123. ### Post single record *HTTP body:* 2012-12-24 18:00:00 We investigate if Santa Clause does fit down the chimney | Remarks | |---------| * The obligatory root tag is `` * A record has to have a `generator="..."` attribute and a _recordtype_ (i.e. a `recordtypeid="..."` or `recordtypename="..."` attribute). * Depending on the _recordtype_ of the posted _record_ there are several _concrete properties_ that must be defined (they are _obligatory_). In case of success the response will look like: 2012-12-24 18:00:00.0 We investigate if Santa Clause does fit down the chimney | Remarks | |---------| * The responces contains the whole record as it lies in the database now. That entails it's final `id`, a timestamp (`generated` attribute) and a full description of the properties with name, type, descpription and so on. * For further specifications of the _concrete properties_ see [wiki:ConcreteProperty]. #### Erroneous properies Now, there are a couple of errors that can occur (cf. [wiki:errorcodes]). The errors that occur due to corrupt concrete properies are described in [wiki:ConcreteProperty]. If any Errors occur on the level of properties, the whole record is handled as unqualified to be posted. Suppose the post body reads: Christmas Eve Does Santa Clause fit down the chimney The first property cannot be parsed to a datetime format. Therefore, the response will be: ... | Remarks | |---------| * The error "Record has unqualified Properties" occures whenever the posted concrete properties of the record are corrupt (i.e. any `` tag is child of a `` tag). * Erroneous records are not stored to the database. #### Erroneous record tags 1) If the recordtype hasn't been indicated, the server returns ... ... 2) The indicated recordtype does not exist: ... ... view Tickets #16 #17 3) The generator has not been indicated: ... ... 4) The record's _recordtype_ demands for a property that isn't present: 2012-12-24 18:00:00 returns: 2012-12-24 18:00:00.0 5) Record doesn't entail any properties: ... ... 6) The indicated ID and name of a _recordtype_ are mismatching (at least one of them exists, but they don't correspond to each other). ... ... ### Post multiple records It is possible to post several records in one go. Here we go through a few scenarios with independent sets of records and closely intertwined ones. #### Independent records *HTTP body:* ... (properties) ... ... (properties) ... ... (more records) ... returns: ... (properties) ... ... (properties) ... ... (more records) ... #### Non-circular interdependent records: *HTTP body:* -1 ... (more properties) ... ... (properties) ... ... (more records) ... returns: 276 ... (more properties) ... ... (properties) ... ... (more records) ... | Remarks | |---------| * The record that is to be referenced by another gets an id less than zero (id="-1"). This id is provisional and will be replaced by the final id, which is the one the record is stored with in the database, in the response (id="276"). #### Circular dependent records *HTTP body:* -1 ... (more properties) ... -2 ... (more properties) ... ... (more records) ... returns: 279 ... (more properties) ... 278 ... (more properties) ... ... (more records) ... | Remarks | |---------| * Likewise,records that are to be referenced by each other get ids less than zero (id="-1" and id="-2"). These are provisional and will be replaced by the final ids in the response (id="278" and id="279"). #### Erroneous multi-posts 1) If any error occurs in a single record, all correct records are nevertheless stored % TODO: (In the future this behavior should be controlled better by an _atomic flag_. See #18). 2) If a referenced record is corrupt, the referencing record is marked with an error tag equally. *HTTP body:* -1 ... (more properties) ... Explanation2 ... (more records) ... returns: -1 ... (more properties) ... Explanation2 ... (more records) ... 3) Self-referencing is not allowed. A self-referencing record will return -2 ... (more properties) ... ... (more records) ... 4) Referencing a non-existing provisional id will return (cf. #19): -2 ... (more properties) ... ... (more records) ... ## DELETE records HTTP-DELETE-requests are to be sent to `http://${host}:${port}/mpidsserver/Record/...`. Default port is 8123. *Example* `DELETE http://${host}:${port}/mpidsserver/Record/1&2&3&4`