On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Thu, Jun 10, 2010 at 2:31 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald <wkornew...@gmail.com> >> wrote: >>> By not supporting string-based primary keys the MongoDB and SimpleDB >>> communities will have to maintain their own version of all Django apps >>> which are already App Engine compatible. Also, writing code for >>> MongoDB and SimpleDB and many other backends will become more annoying >>> because you have to explictly specify a NativeAutoField in all of your >>> models. >>> >>> By supporting string-based primary keys many existing Django apps can >>> work unmodified and those that don't work only need a few *trivial* >>> (!) changes which are even backwards-compatible, so SQL code would >>> continue to work and unit tests would still validate. At least the App >>> Engine and MongoDB and SimpleDB communities could easily share the >>> same code because they have very similar query capabilities. Most >>> probably many more backends could join. This is a ***huge*** and very >>> ***cheap*** advantage and we shouldn't just throw it away. >> >> The issue here is what "supporting string-based primary keys" means. >> At present, AutoField.get_prep_value checks that the pk is an integer >> (or None); if it is a string, it is coerced into an integer using >> int(). This is well established and tested behavior, and it's not >> something we can change without violating backwards compatibility. > > The string coercion can be moved down to the backend level, so the > only issue here is the exception raised by int() if the object is a > string which makes this a very similar (if not the same) issue as the > next one. > >> On top of that, the contract for filter et al currently guarantees >> that filter values are validated at time of query construction, not >> when they are executed. Again, this is behavior that we can't change >> without violating backwards compatibility. >> >> From an initial inspection, it appears that you've broken both of >> these conditions in your branch. If I've missed something, feel free >> to set me straight. > > 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 had some brief discussions with Alex about a possible approach that >> involves treating the hashes that many noSQL backends use as key value >> as if they were integers; Alex was going to do some further >> investigation. I'll leave it up to him to report if he has any >> success. > > 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. 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. Yours, Russ Magee %-) -- 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.
