You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We create an authoring.authors app that has an Author model, and make all Learning Core authoring models link against that instead of the User model.
Rationale
The Learning Core convention to date has been to represent things like created_by using nullable foreign keys to the User table configured via Django settings (which for edx-platform is always the standard auth_user one). But I think that causes a number of issues:
It doesn't properly distinguish between when relationships specifically want to address Authors vs. Learners.
It makes it more difficult to map information into a second instance. If these three problems were created by "Clyde", and we have a publish log and history with that information in it, a full export should be able to preserve that information–even if "Clyde" does not exist in the system being imported into. (This assumes that we have a very rich export format for backup/restore purposes, possibly a SQLite dump of parts of the DB.)
Open Questions
I'm not sure whether this is a single instance-wide Author that's 1:1 with User, or whether we also have a notion of a LearningPackageAuthor relationship.
It doesn't properly distinguish between when relationships specifically want to address Authors vs. Learners.
To me, this doesn't justify creating a new table and needing to maintain it 1:1 with learners. Can't this be addressed with a field type that wraps [foreign key to User] but validates/states that the user is an author? That still allows developers to declare when a relationship is to an author, but doesn't introduce any new table in the DB.
It makes it more difficult to map information into a second instance.
I'm unclear on how this is any different whether we reference "Clyde" via the users table or indirectly via authors ? Are you implying that during import we might import an Author along with a course, but we wouldn't import a User? In that case it would break the 1:1 Author:User assumption so all code that deals with Author would have to know that sometimes it may not be connected to a User.
But there's also a problem that if you import something onto the same system, you'd assume that the Author objects should be correctly linked up with Users as before, whereas is you import onto a different system, you can't assume that their User[username=Clyde] is the same person as Author[username=Clyde] from the export tarball - and how can the import code differentiate these cases? Unless you use emails rather than usernames.
Activity
bradenmacdonald commentedon Sep 3, 2024
To me, this doesn't justify creating a new table and needing to maintain it 1:1 with learners. Can't this be addressed with a field type that wraps [foreign key to
User] but validates/states that the user is an author? That still allows developers to declare when a relationship is to an author, but doesn't introduce any new table in the DB.e.g. instead of
we'd have
I'm unclear on how this is any different whether we reference "Clyde" via the
userstable or indirectly viaauthors? Are you implying that during import we might import anAuthoralong with a course, but we wouldn't import aUser? In that case it would break the 1:1 Author:User assumption so all code that deals with Author would have to know that sometimes it may not be connected to a User.But there's also a problem that if you import something onto the same system, you'd assume that the
Authorobjects should be correctly linked up withUsers as before, whereas is you import onto a different system, you can't assume that theirUser[username=Clyde]is the same person asAuthor[username=Clyde]from the export tarball - and how can the import code differentiate these cases? Unless you use emails rather than usernames.kdmccormick commentedon Feb 23, 2026
@ormsbee Is this something you still think is worth doing? If so, pre-1.0 or post-1.0?
[-]Explicit Author data model in Learning Core[/-][+]Explicit Author data model in openedx-core[/+]ormsbee commentedon Feb 23, 2026
@kdmccormick: I dunno if it's worth doing, but it's definitely a discussion that can wait until post 1.0.