Agreed, they shouldn't know about the named container (the branch). Are you
implying that this method needs to know about the branch?

We need a better way of separating when we're talking about the XBlock
usage_id (which has to encode everything needed to retrieve and update
things in Scope.settings), and the various internal ids used by the split
mongo modulestore.


On Fri, Sep 20, 2013 at 11:11 AM, Don Mitchell <notifications@github.com>wrote:

> In
> common/lib/xmodule/xmodule/modulestore/split_mongo/caching_descriptor_system.py:
>
> > @@ -71,6 +71,10 @@ def _load_item(self, usage_id, course_entry_override=None):
> >      def xblock_from_json(self, class_, usage_id, json_data, course_entry_override=None):
> >          if course_entry_override is None:
> >              course_entry_override = self.course_entry
> > +        else:
> > +            # most recent retrieval is most likely the right one for next caller
>
> Not really. You're comment is incorrect in 2 ways. One having to do w/ my
> choice of implementation and the other having to do w/ the fact that usages
> can indeed have more than one parent.
>
>    1.
>
>    My impl: in the children field, I'm only storing the block_id not the
>    wholely identifying information. The idea is that I'd come up w/ another
>    serialized representation in the future for structure straddling pointers
>    which would avoid the ugly url syntax we use and use something more
>    structural. Thus, a simple id implies, find the thing in this structure
>    with this id. A dict implies, find the thing whose locator is this dict
>    (not impl'd yet).
>    2.
>
>    If course foo has branches draft, alpha, and staging which all point
>    to structure 1111111, and course bar also has branches pointing to the
>    same structure (e.g., source, honors), then the retrieval of any item
>    from that structure could imply that its Locator.course_id is foo or
>    bar and Locator.branch is draft, alpha, staging, source, or alpha. The
>    structure/persistence of the item should have no knowledge of which named
>    containers point to it b/c they can change at any time (point to a
>    successor, delete the reference, etc) w/o affecting the item's persisted
>    state in any way.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/edx/edx-platform/pull/1029/files#r6488996>
> .
>