---
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`