On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald <wkornew...@gmail.com> >> wrote: >>> Why did you revert the AutoField patch? BTW, in the Django-nonrel >>> patch you'll find a few other changes which were related to AutoField: >>> ForeignKey needs to find out the actual database type instead of >>> having a hard-coded IntegerField. We added related_db_type() for this >>> purpose. Maybe you can reuse or adapt some of our code. Still, Django >>> has a few unit tests which assume that assigning a string to an >>> AutoField will fail, so we'll need to find a solution for that >>> (probably by fixing the unit tests). >>> >> >> No, the unittests are quite correct in this instance. I've gone back >> and forth on this, but I believe the semantics of AutoField are "auto >> incrementing field" not "automatically assigned field", and as such >> the integer validation (and the fact that it occurs early) is a part >> of the API and semantics and the tests are correct. Therefore it's my >> intent to add an NativeAutoField, which is basically whatever the DB's >> native auto field is, and has corrospondingly looser constraints, >> pending a discussion with Russ. > > Would this NativeAutoField become the default primary key field from > now on or would MongoDB users have to manually specify that field? The > former would be ok. The latter would make code reuse more difficult. > > Bye, > Waldemar Kornewald > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > >
No, there is far too much code out there that relies on the assumption that the default pk is an integer (and validated as such), including (but not limited to: the tests). I've long been of the opinion you can't just expect code to be portable across entirely different paradigms of databases and have it magically expected to work. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
