Max depth strategy

[adrienbrault]

Hey,

Following #3, here's the depth exclusion strategy.

[adrienbrault]

I'm wondering if the <= should be replaced by <.

Should the MaxDepth annotation mean "include only if current class is at maximum depth X", or "include only if the property will be at maximum depth X" ? (Currently its the second one)

[schmittjoh]

If I'm not mistaken, a @MaxDepth(1) would currently always skip the property, no? If that's the case, I'd use <.

I'm also wondering whether the name makes sense as the depth is not calculated relative to the property on which it is declared. What I would expect is that if I add the annotation on a property is the meaning "serialize the data of this property up to a maximum depth of X", but what it actually means is "serialize the data of this property if the current depth is smaller than X". I'm not sure if we can make this clearer somehow.

[dbu]

when i saw this, i was assuming as well that this controls to what depth the objects in that property get serialized. the other behaviour of saying only serialize if not already that deep is rather tricky, as in the object graph the same object might be at different depths depending on where you start.

what if we would call this setting OnlyAtMaxDepth (or something nicer?) and keep MaxDepth for the other use case?

[calumbrodie]

I agree there needs to be a distinction.
How about RelativeMaxDepth / AbsoluteMaxDepth

[Narretz]

Any news on this? I rebased it on master, it still works, but I was also expecting different behavior, i.e. "serialize this property to a max depth of x" Or, for clarification, I want to use a maxDepth annotation for a class which has children of the same class (tree), and I want to limit the serialization of the children to a certain level. I am confused now if this is in the scope here.

Actually, the way it works now is appropriate. If you have a tree, the other behavior would't limit the serialization of children, because you would e.g. serialize 3 levels deep from each child, as you'd begin at 0 every time. At the moment you begin at 0 and serialize the children until you are at depth 3.

[bendavies]

Is there any movement on this?

[bendavies]

is there an other way to achieve this at the moment?
We'd be looking to use this to limit the depth of Doctrine ManyToMany self referencing associations.

[Narretz]

It should technically work. Starting with the serialized object, you have a depth of 1. When you set MaxDepth on your relation to 2, it will serialize the relation once, and if the relation has the same relation, it will serialize it once more. (if $property->maxDepth < $context->getDepth())

I remember, getDepth() had a little weird behavior, as it will count arrayCollections too, so you might have to look at that. In general, the current Serializer architecture makes it pretty trivial to implement your own Exclusion strategy.

[Bendihossan]

Is there an update for this? Been a few months now. I'm also looking to do this ti limit the depth of ManyToMany self referencing associations.

[alex88]

👍 on this

[calumbrodie]

I can see that the multiple exclusion strategy work has been completed, so this functionality could be combined with groups (Is that right?).

On the subject of the MaxDepth being relative to the property or the overall object graph - I do think there needs to be a distinction (and I would say that only the former is really required - I can't think of a use case for the second one that implementing the former wouldn't solve).

[schmittjoh]

I tend to agree. @adrienbrault, would just a relative depth strategy work for you as well?

[adrienbrault]

@calumbrodie @schmittjoh I do agree :). But it could still be named MaxDepth

[adrienbrault]

Code updated so that the @MaxDepth rule works in a relative way.

[schmittjoh]

Looks good.

Could you add some documentation for the annotation, and the exclusion strategy? I think we could also add something to the context like enableMaxDepthChecks.

[adrienbrault]

@schmittjoh Done!

[schmittjoh]

Great, thanks!