Opened 13 years ago
Last modified 13 years ago
#16448 closed New feature
Single sequence for every table — at Version 1
Reported by: | 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 )
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 , 13 years ago
Attachment: | django_seq.pck added |
---|
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
Note:
See TracTickets
for help on using tickets.
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.