Basic metadata structure

Metadata for entities are always organized into individual XML files. Each file uses the SimpleFM metadata namespace and
the root element must specify at least the class name of the entity, including its namespace, as well as the layout on
which the repository will operate on.

To support auto completion in IDEs, it is advised to include the schema location of the official XSD file. It will be
included in the following example but excluded from all further ones for simplicity reasons:

Field properties

The most common type you are going to define in your metadata are field properties. These are any kind of fields in the
layout which can be mapped to scalar values, Decimal or DateTimeImmutable. When defining a field type, the following
three attributes are mandatory:

name

The name of the field in your layout

property

The property name on your entity

type

The type to which the value will be cast to on your entity. The following built-in types are supported:

boolean: will treat any value other than "0" or "" as true

date-time: will treat the value as DateTimeImmutable

date: will treat the value as DateTimeImmutable and convert it to a pure date

decimal: will treat the numeric value as Decimal object

float: will treat the numeric value as float

integer: will treat the numeric value as integer

nullable-string: will treat the value as string but convert an empty string to null

stream: will treat the value as lazy loaded StreamInterface

string: will treat the value as string

time: will treat the value as DateTimeImmutable and convert it to a pure time

Record ID

Relations

Sometimes your layout defines relations to other tables. For that reason, SimpleFM supports many-to-one, one-to-many and
one-to-one relations. For one-to-many relations, SimpleFM will create lazy-loaded collections, while for both
many-to-one and one-to-one relations it will create a lazy-loaded proxy.

Proxy interface

When using any to-one relation, you need to define an interface name on the target entity's metadata, so that the
repository can create a proxy for it. The only exception is when the relation has
eager hydration enabled.

One-to-many

A one-to-many relation is the simplest of the three relations. It is defined by the following attributes:

Eager hydration

Every relation can be eagerly hydrated when the sparse record contains all information to fully hydrate the parent or
child entity. To enable eager hydration, set the eager-hydration property on the relation to true.

While this gives you additional hydration overhead for each relation, it also saves you from doing additional queries
against FileMaker. Using eager hydration should only be considered when you are using specific relations often enough.