New Annotation @FieldMap #13

New Issue

admin · 2026-01-23T11:34:43+01:00

admin commented

2026-01-23 11:34:43 +01:00

Originally created by @beberlei on GitHub (Oct 10, 2015).

Column stores such as Cassandra and Azure allow to store arbitrary columns for one record. We can support that use case with a @FieldMap annotation on an array property in each entity.

This field map would be populated with all the properties that cannot be mapped to a regular field.

Say the database has the properties:

 id | 1
 name | Benjamin
 country | DE

And an entity:

class Person
{
    public $id;
    public $name;
    /** @KeyValueStore\FieldMap */
    public $fields;
}

Then the country property would be passed into the fields.

This should be done outside of the Storage layer, by checking for existing properties and building up an array of non mapped fields, then checking if a field map exists to write them too. Otherwise they get skipped (like they are at the moment probably).

Originally created by @beberlei on GitHub (Oct 10, 2015). Column stores such as Cassandra and Azure allow to store arbitrary columns for one record. We can support that use case with a `@FieldMap` annotation on an array property in each entity. This field map would be populated with all the properties that cannot be mapped to a regular field. Say the database has the properties: ``` id | 1 name | Benjamin country | DE ``` And an entity: ``` class Person { public $id; public $name; /** @KeyValueStore\FieldMap */ public $fields; } ``` Then the `country` property would be passed into the `fields`. This should be done outside of the `Storage` layer, by checking for existing properties and building up an array of non mapped fields, then checking if a field map exists to write them too. Otherwise they get skipped (like they are at the moment probably).

admin added the enhancement label 2026-01-23 11:34:43 +01:00

admin commented

2026-01-23 11:34:44 +01:00

@beberlei commented on GitHub (Oct 10, 2015):

I jsut looked at the UnitOfWork code, and it just maps the missing columns as "undefined" properties of the Entity itself, so in the example above, the current case would be that $person->country isset and saved to the object if necessary.

This is a bit magic, but changing to the described feature above would be a BC break.

I am unsure how to proceed, to make it possible working with arbitrary data in a nice way.

@beberlei commented on GitHub (Oct 10, 2015): I jsut looked at the UnitOfWork code, and it just maps the missing columns as "undefined" properties of the Entity itself, so in the example above, the current case would be that `$person->country` isset and saved to the object if necessary. This is a bit magic, but changing to the described feature above would be a BC break. I am unsure how to proceed, to make it possible working with arbitrary data in a nice way.

admin referenced this issue

2026-01-23 11:35:05 +01:00

[PR #35] [CLOSED] Yaml driver #65

admin referenced this issue

2026-01-23 11:35:06 +01:00

[PR #36] [MERGED] Mapping drivers #73

Sign in to join this conversation.