Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
-+-
 Reporter:  honeyman |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  multiple autofield   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Csirmaz Bendegúz):

 * resolution:  wontfix =>
 * status:  closed => new

Comment:

 [https://code.djangoproject.com/ticket/373]
 I'm looking to implement composite primary keys like this:

 {{{
 class Tenant(models.Model):
 pass


 class User(models.Model):
 tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
 id = models.SmallAutoField()

 class Meta:
 primary_key = ("tenant_id", "id")
 }}}

 In order to encourage using surrogate keys in composite primary keys, it
 would make a lot of sense to allow non-primary key auto fields.

 We have the following options:
 1. Remove the limitation for databases that support non-primary auto
 fields altogether. We could allow non-primary key auto fields for
 PostgreSQL, for example.
 2. Refactor auto fields so that they are either primary keys OR part of a
 composite primary key. This addresses my use case, but not the others.
 3. Don't use auto fields in composite primary keys. We need an alternative
 in this case.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f3c36f113-aae666d3-424b-448e-ae40-4c7482b4a846-00%40eu-central-1.amazonses.com.

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
-+-
 Reporter:  honeyman |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  multiple autofield   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by logikonabstractions):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Know this is closed, but again just to provide perspective.

 I could really have used this feature actually. I have a project with
 existing data where they use as an ID an auto-increment (just like
 Django's default id). However, they also use a different no_header.
 Sometimes they create revision on their object, so basically their db ends
 up looking like this:

 id no_header suite
 1  1  0
 2  2  0
 3  1  1
 4  3  0
 ..

 So essentially, the no_header is an auto-increment, that only increments
 on the creation of new objects (with suite=0). If an object undergo some
 specific operation, then its no_header remains the same, but suite += 1.

 Which means that the no_header ends up running "behind" the id field, but
 it still needs to be an auto-increment. Of course I can override save() &
 do all that business there, but it would still be so much simpler to just
 have 2 auto-increment fields. IMO this is a conception flaw in the
 database backends - e.g there isn't an obvious reason to limit auto
 increment to a single field, if a separate attributes allows specifying
 what is a primary key. But I digress. Mostly wanted to illustrate a use
 case.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7ebb2291250e63570175501e88ffc7d5%40djangoproject.com.

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:  wontfix   |  Keywords:  multiple 
autofield
 Stage:  Design decision needed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by maccabee):

 I see this is closed, just adding another perspective.

 I'm looking for the same functionality as seanmonstar: an order column
 that is normally creation-order but can be changed.  One workaround I'm
 considering is to use a DateTimeField with auto_now_add=True.  However
 this is space-wasteful (my values should really be 1-20ish rather than a
 long int) and more importantly, it is limited by the precision of the time
 component, which MySQL seems to limit to one second.  That's fine for user
 input speed but not for data import of multiple records.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:  wontfix   |  Keywords:  multiple 
autofield
 Stage:  Design decision needed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * status:  reopened => closed
  * resolution:  => wontfix

Comment:

 As mentioned in the comment when this was closed, the way to get the
 decision reconsidered is to bring it up on the developer's mailing list.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:  wontfix   |  Keywords:  multiple 
autofield
 Stage:  Design decision needed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Without a compelling use-case, this isn't worth doing. One auto-
 incrementing field per model is almost always going to be enough
 (everything else can be derived from the single source, e.g, in the
 `save()` method). Whilst the comments about auto-increment fields not
 being required to be primary key, etc, are valid, Django's `AutoField`
 isn't just an auto-increment field. It's also a primary key field and all
 the other goodies. So there's two ways of looking for that.

 If there's some really strong use-case that's been overlooked here, it can
 be brought up in a thread on django-dev. But "just because we can" isn't a
 reason to do something.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  multiple 
autofield
 Stage:  Design decision needed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * stage:  Accepted => Design decision needed

Comment:

 Replying to [comment:3 newsp...@gmail.com]:
 > MySQL does not allow multiple auto increment fields.
 >
 > ERROR 1075 (42000): Incorrect table definition; there can be only one
 > auto column and it must be defined as a key
 >

 So in fact you can't have multiple !AutoFields in MySQL.  A little
 experimenting with removing the assertions and trying this model:

 {{{
 class MAuto(models.Model):
 auto1 = models.AutoField(primary_key=True)
 auto2 = models.AutoField()
 name = models.CharField(max_length=22)
 }}}

 shows problems on other backends as well.  On both Oracle and sqlite you
 get an error complaining that auto2 cannot be null if you try
 MAuto.objects.create(name="whatever"):

 {{{
 >>> MAuto.objects.create(name="First")
 Traceback (most recent call last):
   File "", line 1, in 
   File "d:\u\kmt\django\trunk\django\db\models\manager.py", line 99, in
 create
 return self.get_query_set().create(**kwargs)
   File "d:\u\kmt\django\trunk\django\db\models\query.py", line 349, in
 create
 obj.save(force_insert=True)
   File "d:\u\kmt\django\trunk\django\db\models\base.py", line 328, in save
 self.save_base(force_insert=force_insert, force_update=force_update)
   File "d:\u\kmt\django\trunk\django\db\models\base.py", line 400, in
 save_base
 result = manager._insert(values, return_id=update_pk)
   File "d:\u\kmt\django\trunk\django\db\models\manager.py", line 144, in
 _insert
 return insert_query(self.model, values, **kwargs)
   File "d:\u\kmt\django\trunk\django\db\models\query.py", line 1004, in
 insert_query
 return query.execute_sql(return_id)
   File "d:\u\kmt\django\trunk\django\db\models\sql\subqueries.py", line
 310, in execute_sql
 cursor = super(InsertQuery, self).execute_sql(None)
   File "d:\u\kmt\django\trunk\django\db\models\sql\query.py", line 1935,
 in execute_sql
 cursor.execute(sql, params)
   File "d:\u\kmt\django\trunk\django\db\backends\util.py", line 19, in
 execute
 return self.cursor.execute(sql, params)
   File "d:\u\kmt\django\trunk\django\db\backends\oracle\base.py", line
 371, in execute
 raise e
 IntegrityError: ORA-01400: cannot insert NULL into
 ("SYSTEM"."MULTIAUTO_MAUTO"."AUTO2")

 >>>
 }}}

 So whatever mechanisms those backends are using to implement an auto-
 assigned auto-incrementing value don't appear to work if primary_key is
 not set to True for an !AutoField.

 It would seem more needs to be done to make multiple !AutoFields work
 across all supported backends than simply removing the two assertions.
 I'm inclined to close this wontfix but I'm also unclear on the scenario
 for when this is useful, as I can find no mention of !AutoField on the
 referenced IRC page, so I'll just put it back to DDN.  The original
 description mentions manual control of one or both of the fields, but that
 contradicts my understanding of how !AutoField values are automatically
 assigned...?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  multiple 
autofield
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by newsp...@gmail.com):

 MySQL does not allow multiple auto increment fields.

 ERROR 1075 (42000): Incorrect table definition; there can be only one
 auto column and it must be defined as a key

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8576: Multiple AutoFields in a model

[Django]

#8576: Multiple AutoFields in a model
---+
  Reporter:  honeyman  | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  multiple 
autofield
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by ElliottM):

  * keywords:  => multiple autofield
  * stage:  Unreviewed => Accepted

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---