Database Configurations
Reference, encoding, timestamps, persistence, compaction...etc.
Here's an example of database configuration object:
ref
ref
type:
string
default:
no default, parameter is required
This a string used as a reference for the database. The database system will use this string in different ways based on how you're running your database.
File persistence: If you're going to use the file persistence adapter, then the file name (and path) will be this string.
IndexedDB persistence: If you're going to use the IndexedDB persistence adapter, then the indexedDB database will be the same as this string.
In-memory only (no persistence): If you're not persisting the data, then this string will have no use at all.
Network connection: If you're connecting to another database instance over the network, then this string will be used to connect to the database instance and it must be in the following format:
tydb://http://127.0.0.1:3000/mydb
.The database will recognize that you're connecting to an over-the-network database since the ref starts with
tydb://
, the next part of the string will be used to recognize the location and database name. Hence:Replace
http://127.0.0.1:3000
with the URL of the database.Replace
dbref
with the ref field of the network database.
When connecting to a database through the network, the instance will only act like a shell and send all operations (creating, reading, updating, deleting... etc.) to the remote instance of the database.
In such case, the only database configurations that matters are the ref
and the model
, all other configurations will be ignored.
model
model
type:
class extends BaseModel
default:
no default, parameter is required
This is the part where strong typing and object mapping occurs. A model should be written to describe your document, the properties of this model are actually used as a type declaration for your document. Also, You ought to use this class for creating new documents.
afterSerialization
afterSerialization
type:
(input:string)=>string
default:
undefined
Use this configuration parameter to implement an encoding/encrypting function. The encrypted string will be used when persisting the data, so when persisting data to the disk - for example, the file will have the resulting string out of this function, not the raw data (The raw data is mostly a stringified JSON object).
This is especially useful for when you want to encrypt the data. However, keep in mind that your encrypting function could have negative effects on performance.
This parameter:
Must be used along side
beforeDeserialization
.Must be the reverse of
beforeDeserialization
.
beforeDeserialization
beforeDeserialization
type:
(input:string)=>string
default:
undefined
This parameter:
Must be used along side
afterSerialization
.Must be the reverse of
afterSerialization
.
corruptAlertThreshold
corruptAlertThreshold
type:
number
default:
0
Although different measures has been taken to avoid data loss and corruption, it is still always a possibility. You can set this parameter to something between 0 and 1, to have some tolerance for corrupted data. It defaults to 0
, i.e. not tolerance for data corruption.
timestampData
timestampData
type:
boolean
default:
false
By default the database will not add the createdAt
and updatedAt
fields. Set this parameter to true, and those fields will have the relevant values as a Date
object.
persistence_adapter
persistence_adapter
type:
class extends Persistence
default:
Persistence (in memory only)
By default the database will not persist any data. All will be saved to memory only, and will be lost once the instance is closed. To persist data, you must use a persistence adapter. I have made the persistence adapter to be pluggable and extensible so you can use different adapters for different uses.
Two adapters are shipped with the database, those are:
IDB_Persistence_Adapter
: Use this one when running in the browser environment, data will be persisted to IndexedDB.FS_Persistence_Adapter
: Use this option when running in NodeJS, data will be persisted to the disk.
Although you can write your own adapter, using those that already ship with the database is recommended, as it has been tried & tested.
Writing your own adapter is also possible and fairly simple. For more about persistence adapter visit the page "persistence adapters" in this documentation.
autoCompaction
autoCompaction
type:
number
default:
0 (no auto compaction)
When persisting data (e.g. into a file), the data will be persisted by appending, this is to avoid re-writing of the whole file in case of removing or updating. This behavior might result in an increase in the persistence layer size (e.g. file size). That's why the database provides you with a function to compact the file size:
In the database configuration you may set the database to call this method automatically on timely intervals:
However, the minimum compaction interval is 5 seconds (5000 ms). Setting it anything lower than 5 seconds will be ignored and will be reset to 5 seconds. Setting it to 0
will disable auto compaction.
reloadBeforeOperations
reloadBeforeOperations
type:
boolean
default:
false
Setting this parameter to true
will make all operations (inserting, reading, updating & deleting documents) preceded by a reloading of the persistence layer (e.g. the file in the disk). This especially useful for cases when two instances of the database are on the same file (i.e. sharing the same data).
Last updated