Reserved Fields
Some fields in Fieldpine have common purpose over all tables where they are present. In general these fields are used for internal purposes and are do not contain business level information. If working directly at the database level you should ignore and never change these fields.
DeleteDtu
Datatype: Date/Time. Date the record was deleted for replication purposes in UTC.
This field is used in some tables to assist with record deletion and replicated systems. Applications will not see this field unless they specifically request it.
If this field contains a NULL, the record is valid. If this field contains a date/time UTC, then this record was or will be deleted after this date time. If you are reading the table directly you should include the predicate "where deletedtu is NULL" to exclude deleted records.
When a row is deleted in a distributed environment, the software may chose to insert the current date/time into this field rather than executing a true "delete" at this time. Client databases that are replicating from this database can then receive these deletes as edits using the normal "changed since" logic. They can elect to immediately delete the record, or wait a period of time if they are also replication sources.
- Request to delete a record made
- Delete changed to edit, setting RVE to now, and deletedtu to now
- Normal use of this table includes the predicate "where deletedtu is null" and no longer sees the record
- Distribution aware applications, see this as a record edit and either delete the row or apply the edit, depending on their needs
- Periodically a clean up task is run to truely delete the rows where deletedtu is a date/time old enough that all continuous replication will have completed.
- If a client periodically does a full table alignment, then it can skip the clean up task if it wishes and let the alignment process delete the rows
- Note, if the deleted rows primary key is re-used, then the deletedtu field is reset to null, meaning the new record is visible again
RVE
Datatype: Double. Contains a last approved edit date/time for replication purposes in UTC.
Values in this fields consist of a UTC timestamp in the format YYYYMMDD.HHmmSSCCC This value can exceed the precision of floating point numbers in some instances so typical use should remove the CCC milliseconds portion. To cater for clock differences the value can be clamped and adjusted by higher ranking servers. Leap seconds will not appear in generated RVE values, if an RVE is generated during a leap second the generator pauses until the leap second is over.
The RVE field can be used to detect recent changes in the database. Whenever the record is changed Fieldpine updates the RVE field. So a select of
select * from table where RVE > 20200823.1340will return any rows updated on or after 23-aug-2020 13:40 UTC.
RVEL
Datatype: Double. Contains edit date/time within the current database for replication purposes in UTC.
Values in this fields consist of a UTC timestamp in the format YYYYMMDD.HHmmSSCCC This value can exceed the precision of floating point numbers in some instances so typical use should remove the CCC milliseconds portion. See details of the RVE field for more information.
RVV
Datatype: String. A list of values indicating the lineage of the record. This value can be used to assist distributed database update conflicts.
The exact contents and handling of this field is not described and has no business level value. Never change or update these field values.
RVS
Datatype: Integer. A bitfield indicating which servers have acknowledged this record. This is a simple method to ensure records are transmitted to all hosts. It is mostly used on log style tables. As each host confirms receipt of this row, the source system sets the bit to say acknowledged.
If a lane generates a log record (LR) it transmits this to each server it uses. It sends with the RVS field of null or zero.
"data": { "key": 12345, "name": "Joan the Great", "rvs": 0 }As it receives acknowledgement from a server, it updates the row and sets the bit for that server. This does not cause an edit transmit.
A server receiving a record, sets it own bit and stores the record. It then transmits to other servers.
"data": { "key": 12345, "name": "Joan the Great", "rvs": 0 } | ||
Server 1 receives packet, sets RVS bit 1, and stores to disk
"data": { "key": 12345, "name": "Joan the Great", "rvs": 1 } | Generating lane sends the same record to all servers |
Server 2 receives packet, sets RVS bit 2, and stores to disk
"data": { "key": 12345, "name": "Joan the Great", "rvs": 2 } |
Sending lane updates it's RVS to indicate accepted in both servers ( RVS 3 = 1 | 2 )
"data": { "key": 12345, "name": "Joan the Great", "rvs": 3 } |
||
Server 1 transmits to Server 2, including the current RVS
"data": { "key": 12345, "name": "Joan the Great", "rvs": 1 } |
Server 2 receives packet, and combines the RVS values, resulting in "3" as value stored
"data": { "key": 12345, "name": "Joan the Great", "rvs": 3 } |