V8-archive: If you try to manage a (existing) table without primary key will result in a SQL with broken sort order

Created on 10 Jul 2019  ·  8Comments  ·  Source: directus/v8-archive

Bug Report

Steps to Reproduce

  1. create / have a table without a primary key but data
  2. activate "managed by directus"
  3. manage all columns
  4. open that table

Expected Behavior

display the content of the table

Actual Behavior

error is thrown because on an uncomplete select statement. There is no column in "ORDER BY", just the table name

Other Context & Screenshots

Technical Details

  • Device:
  • OS:
  • Web Server:
  • PHP Version:
  • Database: mariadb 10.3
  • Install Method: 7.6.1 via docker
wontfix

Most helpful comment

I agree. There's no way the Directus API can function without a primary key.

All 8 comments

I don't know if this is something we'll change in Directus. I realize that some MySQL tables might not need/have a PK, but Directus requires them so that we have a point of reference. Correct me if I'm mistaken, but this seems like it doesn't pass our 80/20 rule.

@rijkvanzanten @bjgajjar ?

I agree. There's no way the Directus API can function without a primary key.

Is there a way that we can error this visually to the user? If a collection doesn't have a PK, we display an error for the user until a PK is added, or at-least to warn them they'll need to add one.

Yes, that makes sense. Can you open a new feature request for that?

Maybe also disabling the "manage" Button with additional text (no primary key, blah...)
or have a "view mode" without any editing

I don't think disabling the manage option will be the best approach, as you're expecting the user to attempt an action before warning them something's wrong, it creates more friction.

Disabling editing would require a lot of work to allow the user to only create a primary-key and nothing else till a PK exists, therefore, the visual is probably the better and most simple approach.

Having a visual error always displayed that _"something important is missing"_, will avoid obfuscation of the potential issue and makes it clear the user needs to do something to proceed.

( _I'm not trying to put your ideas down, just giving my reasoning haha_ :smile: )

I like the idea, @volkerrichert — but that forces the user to fix things through the database directly. Presumably that shouldn't be an issue since this table was setup outside Directus... but still.

If we allow them to "manage" the table, then they can add that PK through Directus if needed. But we will want to make sure #1842 is added so we don't get issues throughout the rest of the platform.

👍 I just want to make sure other users without SQL knowledge doesn't run in that "SQL creation error" :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

metalmarco picture metalmarco  ·  3Comments

cdwmhcc picture cdwmhcc  ·  3Comments

HashemKhalifa picture HashemKhalifa  ·  3Comments

rijkvanzanten picture rijkvanzanten  ·  3Comments

24js picture 24js  ·  3Comments