Currently, the db model has project id as a primary key, and a unique constraint on the name.
However, it does not remove repos if they are no longer present. This makes sense, given its acting as an audit trail.
However, if a user deletes a repo, and then creates a project with the same name, (e.g. repeatedly creating and deleting a demo project for filming video, for instance), this breaks the import, and it tries to import a new project id, but has the same name as an existing one.
A possible and arguably correct change would be a compound primary key of (id, name), but that's not always easy in django.
Maybe we want to add an "archived" feature, and have repos that no longer exist be archived projects
Beyond the import/db question, there's also one of how to present this information to the user.
The archiving approach perhaps helps here.
Currently, the db model has project id as a primary key, and a unique constraint on the name.
However, it does not remove repos if they are no longer present. This makes sense, given its acting as an audit trail.
However, if a user deletes a repo, and then creates a project with the same name, (e.g. repeatedly creating and deleting a demo project for filming video, for instance), this breaks the import, and it tries to import a new project id, but has the same name as an existing one.
A possible and arguably correct change would be a compound primary key of (id, name), but that's not always easy in django.
Maybe we want to add an "archived" feature, and have repos that no longer exist be archived projects
Beyond the import/db question, there's also one of how to present this information to the user.
The archiving approach perhaps helps here.