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 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? 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.
