Here is some more analysis: django.db
1.) There is a problem with ForeignKey, which when given only blank=True causes ValidationError as they do not allow null values. If blank=True, null=True is specified then, there is no problem. The operation of ModelForms is such so as to construct instances at validation time, not at save-time, Null and wrong-model assignments to ForeignKey fields are disallowed prior to save-time. Therefore, there is problem when we try to call is_valid() or save(). Currently if blank=True and null is not True, ValueError is raised. The check being in related.py #399 for ForeignKey. a.) I think we can display a correct message depicting the problem that in ForeignKey with null=True can only be left blank. b.) We can stop the usage of blank=True with ForeignKey, because alone without null=True defined it has no significance and give suitable error message instead of raising an error. null=True alone works perfectly Related: #13776 2.) Unpickling Models and QuerySet from incompatible version. A patch was submitted in regard for this, but it breaks the tests. So, some work needs to be done to fix that.Probably it s because of some fault in django/utils/version.py as far as I have apprehended. Also 'akaariai on github' suggested that we can think of extending this behaviour to do cross-version conversions in case of model unpickling. Upon doing some study and having a discussion on irc with 'apollo13', I have understood how the pickling works and what protocol does django uses. Further I have understood that to do the required, we would need to convert internal data-structures between versions. This could be achived by first finding out the version of the current installation and pickled data. We can store the differences in _meta for models for different versions in a separate file e.g pickle_ver.py. Then accordingly we can define __setstate__() on its basis. We can create a new model instance from the unpickled data, using pickle_ver.py, and then use its state for __dict__. Related: #21430 3.) In certain situations with PostgreSQL, a bogus error message about SET TIME ZONE may be returned. See #3179 (which is closed, but has a description of the problem). The real error message can probably be found in the postgres log file. Till now I have only understood what the problem is. I would need some guidance here, coz I have no knowledge of PostgreSQL as of now. I myself am also trying to consult someone whom I know for this. Although as mentioned for the shell part, we can do the same for views also, we need to figure out how to catch that previous error(due to which we get this behaviour) and then perform cursor rollback with appropriate warning. 4.) #10811 I had written a patch for this but it got stuck at a place leading to failure of two tests. I didn't got the time to look into it much then, I will do that and sort this out. https://github.com/django/django/pull/2162 5.) There has been strange errors being reported because of lack of date[time] CAST conversions in backends. This has been extensively discussed in #7074. Only Oracle implements this correctly. A sample workaround as suggested in the ticket: django/db/models/sql/where.py in make_atom def datetime_cast_sql(self): return 'CAST(%s AS DATETIME)' def rhs_cast_sql(self, db_type): if db_type in ['date', 'datetime']: return 'CAST(%%s AS %s)' % db_type return '%s' In where.py make_atom if value_annot is datetime.datetime: cast_sql = connection.ops.datetime_cast_sql() else cast_sql = connection.ops.rhs_cast_sql(db_type) But the thing is that, we are putting the fix in two different places. What is required here is a single general right hand casting hook so that when values when are passed as strings instead of datetime.datetime objects then we can CAST them appropriately for different backends. For this I am not sure whether this CASTING should be done only for date[time] objects or it might be required in some other cases as well. I need some review here. Only then can I proceed towards writing that single casting function. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/deee2141-9db2-468b-9567-1dc9ca34d963%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
