On Fri, Jun 11, 2010 at 5:25 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald > <wkornew...@gmail.com> wrote: >> That's right. We believe that the long-term advantages of having a >> common AutoField for everyone outweigh the short-term disadvantage of >> a few people having to migrate their code. By far not everyone depends >> on the current behavior and this wouldn't be the first backwards >> incompatible change for Django, so what's the problem with AutoField? >> Do you just want to make sure there is no other solution or is >> changing AutoField inacceptable, in general? > > I've commented on this in detail in a separate thread, but the > summary: Changing AutoField is possible, but only if there is a > transition plan for any user that is relying on the existing behavior.
I've read Django's policy on breaking backwards compatibility and I didn't propose to break compatibility in a single release. I just assumed we'd first discuss if we need to break compatibility and then find out how the transition period should be handled. The transition plan that you proposed sounds pretty reasonable. >> You mean, converting string-based keys to integers? That would result >> in really huge numbers and very ugly URLs. Or did mean something >> different? > > Strictly, the primary key value doesn't have to be converted to > integers; they just need to implement __int__(). We were batting > around some ideas on IRC about how we might be able to exploit this > particular loophole; again, Alex was going to investigate and see what > he could come up with. Hmm, I'm not sure how you want to add __int__() to a pk value passed to a view. In that case you just have a pure string object. Anyway, let's wait for Alex. > As for ugly URLs -- a 32 character hex digest is a pretty ugly URL, > but if that's what Mongos (and others) use as a primary key, then > that's what you have to deal with. Yes, it's still ugly and compared to a hex string a number wouldn't be much longer (I was thinking more in terms of base64 url-safe encoding which would be much shorter than the number representation). Maybe we could also consider converting the pk to a number if we don't find any other solution. It only has the disadvantage that the DB and Django would use different representations of the same primary key which could be annoying during a debug session. 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.
