On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Tue, Jun 8, 2010 at 8:55 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> 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. >> >> 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. > > 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. 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. 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. 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.
