date:20180720

python manage.py inspectdb makes all fields with a default value blank=True, null=True

2018-07-20 Thread Kimball Leavitt

Note: I posted this on django-users 

 and 
was told to come here.

I'm not sure if this is a bug, feature request, or something else.

Summary: *python manage.py inspectdb* makes all fields with a default value 
*blank=True, 
null=True*

I'm using:

   - Ubuntu 16.04
   - Python 3.7.0
   - Django 2.0.4
   - Mariadb 10.2.16
   

Before I get into this, I realize that

   - "Django is best suited for developing new applications"
   - This probably isn't a huge deal or a high priority

...BUT I figured I'd submit this anyway while I was thinking about it. 
Maybe it'll save someone some extra work down the line.


Steps to reproduce:


   - Setup a legacy db in *settings.py* (see 
   https://docs.djangoproject.com/en/2.0/howto/legacy-databases/)
  - Prerequisite: you have a column in one of your tables that has a 
  default value.
  - Example: *test_field int(11) *DEFAULT 1
  - Run *python manage.py inspectdb [--database DATABASE_NAME  [ TABLE 
   ] ] > models.py*
   - Open *models.py*
  - If you don't include *> models.py* you can see the output from the 
  commandline
   - *test_field* will look something like this:
  - *test_field* = models.IntegerField(*blank=True, null=True*)
  - What I would expect:
  - *test_field* = models.IntegerField(*default=1*)
  

What I've been able to dig up:

# from inspectdb.py 

 (line 
144, comments included in the original file)

*142  # Add 'null' and 'blank', if the 'null_ok' flag was present in the*
*143  # table description.*
*144  if row[6]:  # If it's NULL...*
*145  extra_params['blank'] = True*
*146  extra_params['null'] = True*


# from introspection.py 

 in *get_field_description *(line 95, comment is mine)


*86  fields = []*
*87  for line in cursor.description:*
*88 info = field_info[line[0]]*
*89 fields.append(FieldInfo(*
*90   *line[:3],*
*91**  to_int(info.max_len) or line[3],*
*92  to_int(info.num_prec) or line[4],*
*93  to_int(info.num_scale) or line[5],*
*94  line[6],*
*95  info.column_default, # THIS LINE IS JUST WHATEVER THE 
COLUMN DEFAULT IS*
*96  info.extra,*
*97  info.is_unsigned,*
*98  ))*
*99  return fields*


I'm sure there are a lot of things I don't understand about this, but I 
don't think that having a default value should automatically add *blank=True, 
null=True. *
*Is having a default value really a "'null_ok' flag"?*

I think it should only put *blank=True, null=True* if the default is set to 
*NULL* in the column. Otherwise, it should set the default to whatever the 
default value is (ex: *default=1*)

Caveat: I've only tested this with int fields.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2885745-a8bf-4a7a-a114-0eabaae891a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: python manage.py inspectdb makes all fields with a default value blank=True, null=True

2018-07-20 Thread Kimball Leavitt

I opened a ticket for it here --> 
https://code.djangoproject.com/ticket/29583

On Friday, July 20, 2018 at 3:27:33 PM UTC-6, Kimball Leavitt wrote:
>
> Note: I posted this on django-users 
> 
>  and 
> was told to come here.
>
> I'm not sure if this is a bug, feature request, or something else.
>
> Summary: *python manage.py inspectdb* makes all fields with a default 
> value *blank=True, null=True*
>
> I'm using:
>
>- Ubuntu 16.04
>- Python 3.7.0
>- Django 2.0.4
>- Mariadb 10.2.16
>
>
> Before I get into this, I realize that
>
>- "Django is best suited for developing new applications"
>- This probably isn't a huge deal or a high priority
>
> ...BUT I figured I'd submit this anyway while I was thinking about it. 
> Maybe it'll save someone some extra work down the line.
>
>
> Steps to reproduce:
>
>
>- Setup a legacy db in *settings.py* (see 
>https://docs.djangoproject.com/en/2.0/howto/legacy-databases/)
>   - Prerequisite: you have a column in one of your tables that has a 
>   default value.
>   - Example: *test_field int(11) *DEFAULT 1
>   - Run *python manage.py inspectdb [--database DATABASE_NAME  [ 
>TABLE ] ] > models.py*
>- Open *models.py*
>   - If you don't include *> models.py* you can see the output from 
>   the commandline
>- *test_field* will look something like this:
>   - *test_field* = models.IntegerField(*blank=True, null=True*)
>   - What I would expect:
>   - *test_field* = models.IntegerField(*default=1*)
>   
>
> What I've been able to dig up:
>
> # from inspectdb.py 
> 
>  (line 
> 144, comments included in the original file)
>
> *142  # Add 'null' and 'blank', if the 'null_ok' flag was present in the*
> *143  # table description.*
> *144  if row[6]:  # If it's NULL...*
> *145  extra_params['blank'] = True*
> *146  extra_params['null'] = True*
>
>
> # from introspection.py 
> 
>  in *get_field_description *(line 95, comment is mine)
>
>
> *86  fields = []*
> *87  for line in cursor.description:*
> *88 info = field_info[line[0]]*
> *89 fields.append(FieldInfo(*
> *90   *line[:3],*
> *91**  to_int(info.max_len) or line[3],*
> *92  to_int(info.num_prec) or line[4],*
> *93  to_int(info.num_scale) or line[5],*
> *94  line[6],*
> *95  info.column_default, # THIS LINE IS JUST WHATEVER THE 
> COLUMN DEFAULT IS*
> *96  info.extra,*
> *97  info.is_unsigned,*
> *98  ))*
> *99  return fields*
>
>
> I'm sure there are a lot of things I don't understand about this, but I 
> don't think that having a default value should automatically add *blank=True, 
> null=True. *
> *Is having a default value really a "'null_ok' flag"?*
>
> I think it should only put *blank=True, null=True* if the default is set 
> to *NULL* in the column. Otherwise, it should set the default to whatever 
> the default value is (ex: *default=1*)
>
> Caveat: I've only tested this with int fields.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a6aedffd-a04b-4c38-8218-850aa3394364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re:Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

2018-07-20 Thread Zhao Lee

Yes, that's how I got confused by the behavior of get('wordPos') at first , it 
just returns '3', not (2，3)




在2018年07月20 10时54分, "Collin Anderson"写道:


Using your example, the client is sending this string:


?wordPos=2&wordPos=3


It's not an array like ?wordPos=2,3


On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee  wrote:


I have to confess I don’t know much about web development .

I used to expect QueryDict.get(_key_, _default=None_) to return data type that 
client side offered, for example , if client side send {'wordPos':(2,3)} , I 
expect get('wordPos') to return it, whereas the current behavior is far from 
explanation , even using getlist('wordPos'), it just returns ['2','3'], then I 
have to do additional work to convert it back to its first shape, just found 
this inconvenient, so I made this post.
BTW, why integers were converted to strings after the transmission?







在2018年07月19 20时44分, "Florian Apolloner"写道:


On Thursday, July 19, 2018 at 8:52:56 AM UTC+2, Carlton Gibson wrote:
The usual case is to need a single value from the query string, so `[]` and 
`get()` both return scalars. 
`getList()` exists specifically for the case where you do want multiple values. 


I'd like to expand on this, because the current behaviour has even more 
important aspects. The query string is supplied by the user and as such is 
completely untrusted data. If `.get` were to change to return lists if there 
are lists, this would mean that the user could control the data structures in 
the view. This is not something we'd ever want.


Aside from that it is technically impossible to change the behaviour of get to 
return lists: What would ?some_param=1 result in? Would it all of a sudden be a 
list with one item? Since there is no difference between a scalar value and a 
one item list in terms of query strings, this has to stay the decision of the 
developer. They are the only ones knowing how the data should look like and can 
handle it accordingly.



Cheers,
Florian


--
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4e15b2a8-895e-4c43-9b61-5dce2759d23c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




 

--
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/47f81b86.5f.164b581f067.Coremail.redstone-cold%40163.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/snBepnO5AjY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7i7YOrqmWamGo5vwr8RW0L6EBuvdsBEAh-0LjDwNtNEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4dcd0e64.16.164bab1a016.Coremail.redstone-cold%40163.com.
For more options, visit https://groups.google.com/d/optout.

python manage.py inspectdb makes all fields with a default value blank=True, null=True

Re: python manage.py inspectdb makes all fields with a default value blank=True, null=True

Re:Re: Re: The behavior of QueryDict.get(_key_, _default=None_)

3 matches

Site Navigation

Mail list logo

Footer information