[TYPO3-team-core-v5] RFC: Open question on support for associative array properties in persistence

[Bastian Waidelich]

Karsten Dambekalns wrote:

Hi Karsten,

maybe I'm still not getting this right, but...

>> Let's take the Blog for instance:
>> Right now _posts_ is an array-property of _Blog_ which forces us to 
>> load all posts into RAM to find a single post by its UUID.

> Well, lazy loading should be applied only if needed, not the other way 
> around. :)

Ok, lets I have 3 Blogs with 10000 posts each. I _do_ need lazy loading. 
How do I apply it?

>> And we have to instantiate a _Blog_ instance to retrieve its _posts_, 
>> there is no "find all posts of blog xy" AFAIK.

> Well, that's how aggregates work in that regard. And it's DDD, otherwise 
> you are already very close to "SELECT FROM posts WHERE blog_id=34"... 
> When you have the Blog instance, your posts are already there

ok, but DDD apart.. What if you want to display all comments from author 
x of posts tagged with "PHP" in Blog y?
If there is no notion of "parent object", this seems to be quite a 
tedious and expensive (memory & performance wise) task.


>> And then - back to the topic - wouldn't _posts_ rather be some kind of 
>> Collection of F3::Blog::Domain::Post, and the "array key" the identifier?

> Of course that makes sense, although not strictly needed (if you make 
> sure you only accept objects of the right type in, say, add() you don't 
> need a typesafe collection).

Let's take a common example, a user with one or more images.
We probably don't want to store an array of filename strings anymore, 
but some kind of collection to an image domain object, right?
Now I'd love to have some mechanism provided by the framework.. and I 
wouldn't have to implement all the "array functions" I needed otherwise, 
but could directly query the sub entities.
At first I thought, you would simply add an imageRepository but someone 
said that would not be the right way as it crosses some cutting concerns 
or so ;)
But now that I think about it.. wouldn't that be nice:

@entity
class User {
	/**
	 * @var string
	 */
	protected $name;

	/**
	 * @var ImageRepository
	 */
	protected $images;
}

@entity
class Image extends File {
	...
}

and I could directly access the query helpers from the image repository 
from within the user object.. and the framework would know about the 
connection between the two objects and could provide utility-methods 
like $user->getChild('image', 'imageUUID') and performance optimizations.

But back to the actual question (sorry, I got carried away ;) If you 
store an object with an array-property in the CR i would preserve keys 
unless stated differently.

Bastian