On Fri, Jun 11, 2010 at 12:22 AM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Thursday, June 10, 2010, Dj Gilcrease <digitalx...@gmail.com> wrote: >> Wouldnt an autofield like http://dpaste.com/hold/205665/ work where >> connection.creation.auto_field_base_type is set to int by default in >> django/db/backends/creation.py but could be overridden by an >> individual backend to be str or unicode or whatever? > > That's pretty much how Django-nonrel does it. The problem which > Russell talked about is that some developers seem to do something like > > def myview(request, pk): > try: > query = MyModel.objects.filter(pk=pk) > except ValueError: > # oh no, someone passed a string instead of a number! :( > ... > try: > result = query.get() > except MyModel.DoesNotExist: > ... > > With the poposed AutoField change the exception could not be raised at > query construction time (the first try: block), but at execution time > (the second try: block), so a more flexible AutoField would break the > code above. Though, maybe the exception would become > ObjectDoesNotExist instead of ValueError, so it wouldn't really break > the code above, but it would behave in a different way because the > first except: clause wouldn't be executed, anymore. Russell, please > correct me if you meant something different.
No - you've understood me correctly. > So, the question (as far as I understand) is whether the code above is > actually used by so many developers that you could justify making > NoSQL support a second-class citizen. Or, to put a different, but equally melodramatic spin on it: are we going to break backwards compatibility and force an unknown proportion of our existing userbase to go through a painful audit process to identify places where they are relying upon a particular ORM feature? As a project, Django takes backwards compatibility *very* seriously. Our existing user base is just as important as the user base we may acquire as a result of adding new features. We're not going to sacrifice (or massively inconvenience) one user base in order to acquire another. That doesn't mean we can't or won't make changes. However, it does mean that we need to be acutely aware of the impact those changes will have on users, and provide a staged transition plan for users that may be dependent on the old behavior. Thinking aloud, one possible approach to handling this transition might be to use the contents of DATABASES. Any current Django user will have a DATABASES (or DATABASE_ENGINE) setting that describes one or more SQL databases. It won't be until we (officially) add non-SQL databases that this AutoField issue will actually manifest. Therefore, we could inspect the DATABASES list, and if the user has a non-SQL database in their DATABASES list (as identified by some flag in the backend), the behavior of AutoField could change to a 'passthrough' that is validated on the backend. If the user only has SQL backends, the field will behave as it does currently, but raise a PendingDeprecationWarning; over the next couple of releases, this would escalate to a full Warning, before the feature is completely removed. This approach provides the functionality that is required to support non-SQL backends right now, but also provides a long term plan for transitioning users to the new behavior. Existing apps will continue to work, but may break if you use them in a project that utilizes noSQL. However, part of the task of adopting NoSQL in your Django project would be ensuring that all your dependency apps have been updated to be compliant with the new-style AutoField validation behavior. Now - like I said, I'm just thinking aloud here. I haven't fully thought through the consequences of this change. I'm not necessarily advocating it as a viable solution. What I want to point out is that there are ways to accommodate change that don't require us to break backwards compatibility at a single version. Any proposal to modify Django in a backwards incompatible way that *doesn't* have a transition plan is a non-starter. 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.
