about the design philosophy behind the display_id in Medusa orders.

[leosin]

Hi there! I'd like to ask about the design philosophy behind the display_id in Medusa orders.

I understand that display_id exists to provide customers with a simple, memorable order number, which is definitely practical. However, I've noticed it uses a globally incrementing approach, which has me a bit puzzled.

From a business perspective, this sequential order numbering seems to inadvertently expose store volume information. For instance, if a customer sees their order number is #1234, they can roughly infer how many total orders the store has processed. For new merchants, this might affect customer confidence in the brand's credibility; for established merchants, competitors could easily analyze business growth patterns through order numbers.

I'm wondering:

1. Did the Medusa team consider this aspect when designing this feature?
2. Are there recommended ways to customize order number generation rules, such as using random numbers or adding prefixes?
3. Or am I misunderstanding the purpose of display_id - does it have other design considerations I'm missing?

I might not be understanding this deeply enough, so I'd appreciate everyone's insights. After all, platforms like Shopify use non-sequential order numbers by default, so I'm curious about Medusa's design rationale in this regard.

Thanks!

[bqst]

I've successfully implemented a migration to replace Medusa's default sequential display_id with random 7-digit numbers for better order privacy and UX.
The main issue was that Medusa's order table has a default constraint nextval('order_display_id_seq'::regclass) on the display_id field, which prevented the trigger from working properly since the value was already set before insertion.

import { Migration } from "@mikro-orm/migrations"

export class Migration20250701140000 extends Migration {
  override async up(): Promise<void> {
    // 1. First, remove the default value
    this.addSql(`
      ALTER TABLE "order" ALTER COLUMN display_id DROP DEFAULT;
    `)

    // 2. Create the random ID generation function
    this.addSql(`
      CREATE OR REPLACE FUNCTION generate_random_display_id()
      RETURNS INTEGER AS $$
      DECLARE
        random_id INTEGER;
        max_attempts INTEGER := 100;
        attempts INTEGER := 0;
      BEGIN
        LOOP
          -- Generate random 7-digit number between 1000000 and 9999999
          random_id := floor(random() * 9000000 + 1000000)::INTEGER;
          
          -- Check if this ID already exists
          IF NOT EXISTS (SELECT 1 FROM "order" WHERE display_id = random_id) THEN
            RETURN random_id;
          END IF;
          
          attempts := attempts + 1;
          IF attempts >= max_attempts THEN
            RAISE EXCEPTION 'Could not generate unique display_id after % attempts', max_attempts;
          END IF;
        END LOOP;
      END;
      $$ LANGUAGE plpgsql;
    `)

    // 3. Update the existing orders with random display_ids
    this.addSql(`
      DO $$
      DECLARE
        order_record RECORD;
        new_display_id INTEGER;
      BEGIN
        FOR order_record IN SELECT id FROM "order" LOOP
          new_display_id := generate_random_display_id();
          UPDATE "order" SET display_id = new_display_id WHERE id = order_record.id;
        END LOOP;
      END $$;
    `)

    // 4. Create the unique index after updating the existing data
    this.addSql(`
      CREATE UNIQUE INDEX IF NOT EXISTS "IDX_order_display_id_unique" ON "order" (display_id);
    `)

    // 5. Create the trigger function (modified to be more robust)
    this.addSql(`
      CREATE OR REPLACE FUNCTION set_order_display_id()
      RETURNS TRIGGER AS $$
      BEGIN
        -- Seulement si display_id n'est pas déjà défini
        IF NEW.display_id IS NULL THEN
          NEW.display_id := generate_random_display_id();
        END IF;
        RETURN NEW;
      END;
      $$ LANGUAGE plpgsql;
    `)

    // 6. Create the trigger
    this.addSql(`
      DROP TRIGGER IF EXISTS order_display_id_trigger ON "order";
      CREATE TRIGGER order_display_id_trigger
        BEFORE INSERT ON "order"
        FOR EACH ROW
        EXECUTE FUNCTION set_order_display_id();
    `)
  }

  override async down(): Promise<void> {
    // Drop the trigger
    this.addSql(`DROP TRIGGER IF EXISTS order_display_id_trigger ON "order";`)

    // Drop the trigger function
    this.addSql(`DROP FUNCTION IF EXISTS set_order_display_id();`)

    // Drop the random ID generation function
    this.addSql(`DROP FUNCTION IF EXISTS generate_random_display_id();`)

    // Drop the unique index
    this.addSql(`DROP INDEX IF EXISTS "IDX_order_display_id_unique";`)

    // Restore the original DEFAULT constraint
    this.addSql(`
      ALTER TABLE "order" ALTER COLUMN display_id SET DEFAULT nextval('order_display_id_seq'::regclass);
    `)
  }
}

[Gintasz]

Could you tell how did you run this migration? The official documentation is a bit lacking. I copied the file into src/migrations of backend but npx medusa db:migrate doesn't seem to trigger the migration, as no new row appears in mikro_orm_migrations table in postgresql.
EDIT: I had to create new module and put migration script there. Also added name attribute in the Migration class but don't know if it was needed.

[bqst]

Exactly! I created a dedicated module for my business-specific features (including the migrations) to keep them separate from the core Medusa logic. This approach ensures me better maintainability and avoids conflicts with future Medusa updates.

[leosin]

I'm curious if other people who use medusa don't need this display_id, or if they don't care about this part of the privacy.
@Gintasz @bqst

[bqst]

I'm also wondering why this regression from V1 to V2.

Also note that the code I provided creates an issue in the admin dashboard. Orders are sorted by default by display_id (and not creation date) which creates a problem with the random generation of display_id.