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
So... we've run into issues again. None of the database tables have a proper primary key (a column that is non-null and unique). Because the database tables store every version of the table together, only the combination of the id and version_id are unique. In SQL speak, this would be a composite primary key. The Django admin portal requires the presence of a primary key. The newest alpha of Django includes support for composite primary keys, but they still aren't supported in the admin portal. These are the options:
Add another column to each table that contains a unique id. We'll then have 3 different id columns.
Trim down each table to its most recent version, version 14. Track the previous versions and changes in a different manner. This will make the id column a proper primary key. It might, however, make previous versions inaccessible or more complex to access for the SO.
Keep using Django, but build our own admin portal instead of using Django's admin portal.
Move away from Django entirely, trying to find something else that will generate an admin view for us without requiring primary keys.
@raarielgrace I'm in favor of either option 1 or 2, so long as we keep that information available to the service owner in some way i think option 2 makes the most sense.
As a farmer I want to add my crops to individual fields So That I can see the different nutrients needed
Additional Context
Acceptance Criteria
The text was updated successfully, but these errors were encountered: