[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