Skip to content

Assume that scope IDs are opaque key objects #708

Closed as duplicate
Closed as duplicate

Description

@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

Activity

  1. kdmccormick commented on Jan 12, 2024

    @kdmccormick
    MemberAuthor

    @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?

  2. bradenmacdonald commented on Jan 12, 2024

    @bradenmacdonald
    Contributor

    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

  3. self-assigned this
    on Jan 31, 2024
  4. kdmccormick commented on Jan 31, 2024

    @kdmccormick
    MemberAuthor

    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.

  5. kdmccormick commented on Feb 14, 2025

    @kdmccormick
    MemberAuthor

    Moving discussion/tracking to the relevant DEPR ticket...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions