[TYPO3-mvc] Limit the "depht" of object relations

Frenck Lutke frenck at innologi.nl
Fri Jun 28 16:14:54 CEST 2013


Hi Jan,

On 28-6-2013 10:35, Jan Kornblum wrote:
> Last night i changed the relations in my domain model and added @lazy
> annotations (to parent objects and child object storages).Curiously,
> now some parts of the application do not work as they did before: A not
> persistable property, being set based on certain criteria while looping
> through the (bidirectional) relation levels (A <-1:n-> B <-n:1-> C)
> isn't set any longer (or maybe just the object comparison fails)

Given that instances are now of a different class, a failing object 
comparison is quite possible, especially with LazyLoadingProxies.

Note that:
a) the LazyObjectStorage extends ObjectStorage, so you can keep 
instanceof ObjectStorage checks in either case
b) LazyObjectStorage count() results are inconsistent after adding or 
removing objects to it. It reads out the initial integer count value 
that was retrieved from database, rather than doing a count() on the 
ObjectStorage's internal array
c) while LazyObjectStorages and LazyLoadingProxies call their 
initialization methods on calling the original's public methods, there 
are cases where you would need to initialize them manually.

If some of these things are more hassle than its worth to you, are you 
sure you need i.e. A and C to be lazy in B? Would it provide a real benefit?

> The strange thing with it is the following: As soon as i var_dump()
> anything at the right place, everything works as before (like without
> lazy loading).

Well, what was the result of trying out your previous var_dump() 
question with lazy annotated children? Is your experience inconsistent?

> And i figured out something else which seems strange: When trying around
> with the relations and lazy lading, i've changed a persistable property
> of an object by it's setter. Although i don't ask the repository to
> update anything on any place, this property has been saved to the db,
> obviously just because the var_dump() statement?

Are you sure this has anything to do with the lazy-experimentation / 
var_dump() usage?

> Now i am even more astonished.

Welcome to the magic of extbase 1.3, until you start debugging its 
internals seriously.

To be fair, which TYPO3 4.5 release are you running? If you're able to, 
you can really benefit from developing with newer versions. A lot of 
things have been fixed/improved upon with later extbase releases and 
backported TYPO3 FLOW improvements. i.e. since extbase 6.1, persistence 
of changed objectStorages no longer magically happens (which is a good 
change because it is more consistent).

Also, what number of records for A, B and C is your typical use case? 
Older extbase versions are notably slower than newer versions, 
especially when interacting with huge datasets. These are factors to 
consider.

HTH,
Frenck


More information about the TYPO3-project-typo3v4mvc mailing list