# Dynamic Fields

> eXtremeDB supports both "fixed size" fields such as `int`, `float` `date`, etc. and also dynamic or "variable size" fields of type `string`, `vector`, `varbinary`, `sequence` and `optional struct`. The latter are dynamically extendable, i.e. they can be created, enlarged and reduced in size during runtime. These field types and optional structure fields are not stored in the object's fixed size memory layout, but rather as pointers to memory pages where the actual data resides.

> To achieve this eXtremeDB uses two kinds of memory layouts for objects. The first is the fixed record layout that is not able to change its size but is able to fit several instances (objects) of the class on a single page. The second is a memory layout composed of a tree of small memory pages. This provides the ability to change the size of a class instance. This tree-like layout accomodates dynamic fields, but with additional overhead that needs to be taken into account during the database schema design phase of development, while fixed size records save data in a more compressed form of storage.

> A dynamic field requires only two bytes (for `compact` classes less than 64K) or four bytes (for regular classes) in the memory layout for an empty dynamic field. When a value is put into the field it makes the class instance (object) larger. Removing or decreasing the value's size reduces the size of the object instance, but retains the normal memory overhead for the tree-like layout. The eXtremeDB runtime provides an internal mechanism for memory defragmentation and performs Automatic compaction of dynamic fields.

> There are two special considerations when performing operations on dynamic fields :

> > 1. A member of a `vector` of `structs` needs to be allocated before a put operation can be performed.

> > 2. The get operation with a field of type `string`, `wstring` or `nstring` adds a null-terminator into the receiving buffer only if the buffer is large enough.