Assume that scope IDs are opaque key objects

[kdmccormick]

In edx-platform, which accounts for virtually all of real-life xblock usage, a block's def_id and usage_id are assumed to be instance of opaque key classes.. This is helpful and lets assume other things too. For example, every XBlock usage in edx-platform will have an associated UsageKey, which, in turn, will have an associated LearningContextKey.

This XBlock repo, though, doesn't make that assumption. As of right now, xblock-sdk, the only other known XBlock Runtime, uses strings for scope IDs. We would like to update both this repo as well as xblock-sdk to use opaque key objects. Discussion: #690 (comment)

Tasks

• Update this repo
• Update xblock-sdk: Use opaque key objects instead of strings for block scope IDs xblock-sdk#342

[kdmccormick]

@bradenmacdonald , Here's the current ScopeIds definition:

class ScopeIds(namedtuple('ScopeIds', 'user_id block_type def_id usage_id')):
    ....

I'm thinking we could change it to something like:

class ScopeIds(NamedTuple):
    user_id: int  # or just 'object'?
    block_type:  str
    def_id: DefinitionKey
    usage_id: UsageKey

do you agree?

[bradenmacdonald]

This is great, @kdmccormick

Just need to investigate the type of user_id a bit more. I know it can be None sometimes when an XBlock is not "bound" to a particular user. And at least in the "new runtime", an anonymous user gets a string ID. So I think it should be typed as int|str|None.

Example: https://github.com/openedx/edx-platform/blob/2cd1410d9951f0b5cd1639f25dd34e191d4d75f3/openedx/core/djangoapps/xblock/runtime/runtime.py#L110-L117

[kdmccormick]

I'm currently doing this in tandem with #707 , implemented by #713.

My thinking is that we'll make the change, bump the major version of XBlock, and pin xblock-sdk to an older version of XBlock.

Following up, we should either deprecate xblock-sdk, or a find a maintainer for it who is willing to remove the XBlock version pin.