Opened 13 years ago

Last modified 13 years ago

#16448 closed New feature

Single sequence for every table — at Version 1

Reported by: wiesiek@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Aymeric Augustin)

Hi,
I am a newbie in Django,
but IMHO in database layer design Django does not follow DRY principle.
I do not understand, why Django uses different sequence for every table.
Having single sequence for all tables is much better than having
sequences for different tables regarding
maintenance, sharding, security et.c. I give you and example package,
that can greatly simplify many mentioned tasks.
Just use django_seq as id generator on any django table

CREATE OR REPLACE PACKAGE django_seq IS

  FUNCTION NEXTVAL RETURN NUMBER;
  FUNCTION CURRVAL RETURN NUMBER;
END django_seq;
/
CREATE OR REPLACE PACKAGE BODY django_seq IS

  last_val NUMBER;
  shard_no NUMBER;

  FUNCTION NEXTVAL RETURN NUMBER IS
  BEGIN
    SELECT to_number(to_char(mr_inne_seq.nextval) || lpad(shard_no, 4, '0')) ||
           ltrim(to_char(MOD(abs(hsecs), 1000000), '000000'))
      INTO last_val
      FROM sys.v_$timer;
    RETURN last_val;
  END;

  FUNCTION CURRVAL RETURN NUMBER IS
    no_current_value EXCEPTION;
    PRAGMA EXCEPTION_INIT(no_current_value, -8002);
  BEGIN
    IF (last_val IS NULL) THEN
      RAISE no_current_value;
    END IF;
    RETURN last_val;
  END CURRVAL;

BEGIN
  --- the code below can use database table lookup
  shard_no := 5;

END django_seq;
/

Change History (2)

by wiesiek@…, 13 years ago

Attachment: django_seq.pck added

comment:1 by Aymeric Augustin, 13 years ago

Description: modified (diff)
Triage Stage: UnreviewedDesign decision needed

Fixed formatting (please use preview).

As is, I can't tell where we'd use your block of code, what are its advantages and drawbacks, and whether it is backwards-compatible. We're web developers, not DBAs :) All I can say is that it is far from trivial.

As a consequence, this ticket is likely to fall into the "yes, Django could have been designed differently, but it isn't" bucket, but I'll leave it open for now in case someone's interested.

If you want to see this in Django, you will have to 1) produce a patch 2) explain why it is useful — your explanation is mostly hand-waving at this point.

Note: See TracTickets for help on using tickets.
Back to Top