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

[Jan Kornblum]

Hi again,

> 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?

Maybe it really doesn't make any sense to prooceed with the lazy 
approach hear as in most controller actions i need to be able to access 
A->B->C, only in few actions i must just access A->B or C->B (1 or 2 
levels).

>> 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?

You mean the example you've posted? I still have to try it this 
weekend...

>> 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?

No. this might happen also without lazy. Not tested yet.

>> Now i am even more astonished.
>
> Welcome to the magic of extbase 1.3, until you start debugging its internals 
> seriously.

It's time to learn how to debug the right way with netbeans / xdebug 
(or anything)

> 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. 

I know :( In this case it still must be last 4.5.x, but the next 
planned extension will be 6.1.

> 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).

That is definitly good to know!

> 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.

The 1.3 case has 120 A's, 830 B's and 14 C's. Not really a lot, but 
causing some load because of the lots of 3-level operations.

> HTH,
> Frenck

Thank you very much for your time spent on this, this list is great!

Nice weekend,
Jan