Exercise 2: Why the Controller's Breadcrumb Loop Has the Same N+1 — Possible Solution
====================================================================

WHY IT'S THE SAME PATTERN
------------------------------
Per this chapter, the Controller's own breadcrumb loop (carried over from Chapter 4) walks $node->parent repeatedly inside a while loop - each access to ->parent that hasn't already been loaded on that specific model instance triggers its own fresh, separate database query. This is structurally identical to the N+1 pattern Django Rebuild 6 found in its own breadcrumb-building code, just expressed in Eloquent's relationship syntax instead of Django's.

WHY IT'S STILL TREATED AS ACCEPTABLE
------------------------------
Per this chapter, the same reasoning Django's own chapter used applies here unchanged: breadcrumb depth on this site is bounded - it never goes more than a handful of levels deep - so the "N" in this particular N+1 stays small no matter how many pages exist site-wide. A handful of small extra queries per page view is a real but genuinely minor cost, worth naming honestly rather than pretending the code is already fully optimized, but not urgent enough to demand an immediate fix on its own.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the breadcrumb loop's repeated ->parent access as the same N+1 pattern found in Django's own equivalent code, and correctly explains why the bounded, small depth of this specific use case makes it an acceptable, honestly-named cost rather than a real problem demanding immediate attention.