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. FYI, the admin interface, contrib.auth, contrib.sessions, contrib.sites, etc. work unmodified with our MongoDB backend. If Django requires an explicit NativeAutoField we all lose those features. Also, the Django-nonrel website (http://www.allbuttonspressed.com/) works unmodified on App Engine, MongoDB, and SQL and we didn't even try to design it like that, so it's very well possible to write "ultra-portable" apps, even if they're only simple apps. Moreover, many reusable Django apps don't explicitly use primary keys in their queries, so they don't have an AutoField problem, at all. The point is that we can very well expect that *NoSQL*-compatible model code will magically work across a broad set of *NoSQL* databases. SQL code is a different story, but we can at least create a standard for NoSQL databases. In the worst case we'd split compatiblity between simple key-value stores and document DBs with real query capabilities, but at least within each group code can be shared. That's still much much better than doubling the number of incompatible NoSQL Django apps and development concepts. 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.
