Opened 14 years ago
Last modified 14 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 , 14 years ago
| Attachment: | django_seq.pck added |
|---|
comment:1 by , 14 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.