Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ComponentType model #147

Closed
wants to merge 23 commits into from
Closed

Conversation

ormsbee
Copy link
Contributor

@ormsbee ormsbee commented Jan 31, 2024

@kdmccormick, @bradenmacdonald: This is meant to be reviewed after #143 merges, and builds on top of it.

refactor: normalize component types with ComponentType

Prior to this commit, Components encoded their namespace + type info as
two columns on the Component model itself. This wasted a lot of space on
a very common index lookup–many rows of ('xblock.v1', 'video'),
('xblock.v1', 'problem'), and ('xblock.v1', 'text'). But worse, the lack
of a separate ComponentType model meant that there was no first class
entity to store per-type policy data against. For example, we might want
to say "the following types are supported by libraries, while these
other types are experimental", or "these types are enabled for these
orgs", etc.

Components are required to have a ComponentType. We're rewriting the
first migration for the components app here, since this app hasn't been
added to edx-platform yet.

This commit adds a number of features needed to accomodate content
libraries. It also tunes a number of queries to elminated n+1 fetch
issues when tested with libraries, by using select_related more
liberally, and following cached relationships instead of re-fetching
things from the database.

As part of this general tuning, PublishableEntityVersion.version_num was
reduced to a 4-byte PositiveIntegerField instead of using the 8-byte
PositiveBigIntegerField. This should save us a bit of space with our
indexes while still allowing for over two billion versions for any given
PublishableEntity.
Prior to this commit, Components encoded their namespace + type info as
two columns on the Component model itself. This wasted a lot of space on
a very common index lookup–many rows of ('xblock.v1', 'video'),
('xblock.v1', 'problem'), and ('xblock.v1', 'text'). But worse, the lack
of a separate ComponentType model meant that there was no first class
entity to store per-type policy data against. For example, we might want
to say "the following types are supported by libraries, while these
other types are experimental", or "these types are enabled for these
orgs", etc.

Components are required to have a ComponentType. We're rewriting the
first migration for the components app here, since this app hasn't been
added to edx-platform yet.
@kdmccormick kdmccormick self-assigned this Jan 31, 2024
@ormsbee ormsbee closed this Jan 31, 2024
@ormsbee ormsbee deleted the component-types branch January 31, 2024 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants