keepdb with flush option

[Brice Parent]

Hi everyone,

Right now, when testing, we have the choice to either :

 * create a new empty database to launch the tests with
 * reuse an existing database with all its data (--keepdb)

I think we're missing a third option, here :

 * reuse an existing database, but flush its contents before (or after,
   or both) launching the tests (--flushdb? --keepdb --flush?)

The reason for that is that we don't always want to/may give django's db 
user the ability to create and delete database, but we may still want to 
start with a fresh one (otherwise, we wouldn't need --keepdb, it would 
be the normal behaviour). As there's already a management command to 
flush the db, I don't expect this to be a huge work, but I might be 
missing something. If there's already a way to do that without creating 
a custom test runner, thanks for pointing me at it and sorry for your time!


Any thoughts ?

-Brice

--
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/1cce7310-792c-7693-fbd4-ccba9d463f38%40brice.xyz.
For more options, visit https://groups.google.com/d/optout.

Re: ticket 28404

[Carlton Gibson]

[Better Subject] Fix admin change list display of empty string values. 

I'll summarise; I'd like to elicit any objections. 

The issue is that the admin change list doesn't display the "empty value" 
placeholder for empty strings, 
which is the recommended way of handling "nullable" CharFields. 

The image attached to the issue demonstrates the issue nicely: 



These rows won't even be clickable. 

Options: 

1. Make the existing admin `empty_value_display` option also handle empty 
strings. 
2. Add a new admin option for empty strings, separate from `None` 
(null=True) cases. 

We have PR that's not too far off for option 1. 

More to the point I'm in favour of option 1 because: 

* We have enough admin options already
* The empty string is just how text-type fields handle the `null` case. 
(i.e. this should already be the behaviour.)

*Are there any reasons we can't adjust `empty_value_display` to also be 
used for empty strings?*

Original Issue: https://code.djangoproject.com/ticket/28404
PR: https://github.com/django/django/pull/9391

Thanks for the input all!

Kind Regards,

Carlton





-- 
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/92b12dbc-ace6-4d72-9234-5563625446b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Method for allowing different `MAIL FROM` or `Return-Path` and `From` headers.

[Ian Campbell]

Hi - I have a question about an issue I've recently run into with Django. 
It relates to creating a separate `Return Path` and `From` header in an 
email using Django.

The current solution is undocumented, but discussed 
here: https://code.djangoproject.com/ticket/9214

To create a separate `Return Path` and `From` header in an email, one puts 
the `Return Path` in the `from_email` parameter, and creates a separate 
`From` header in the `headers` parameter. The current Django code can be 
seen 
here: 
https://github.com/django/django/blob/a38ae914d89809aed6d79337b74a8b31b6d3849a/django/core/mail/message.py#L256

My question is around the fact that this seems to be a bit of a hack. Does 
it make more sense to create a PR to document this "feature" in the docs, 
or would it make more sense to create a PR to deprecate the old way of 
doing things in favor of a separate from_email and return_path parameter? 
Or something else?

I'd love to contribute one or the other, to save others time in having to 
dig through and find a nine year old ticket to figure out how to set the 
`Return Path` parameter. I thought to post here before creating an issue in 
the Issue Tracker because I'm not sure whether the current implementation 
would be considered best practice or not. Thanks for any suggestions!

-- 
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/a9457a83-a6ad-4384-9cf7-99108725985a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ticket 28404

[Collin Anderson]

Hi Carlton,

There are some cases where I really do want an empty string displayed
(though not in a linked column). Maybe only use it only when it's an
auto-linked field/column? Or maybe only use this behavior in
display_for_field()? (So if you use a custom function/method, you can still
have full control.)

Thanks,
Collin


On Wed, Feb 7, 2018 at 5:30 AM, Carlton Gibson 
wrote:

> [Better Subject] Fix admin change list display of empty string values.
>
> I'll summarise; I'd like to elicit any objections.
>
> The issue is that the admin change list doesn't display the "empty value"
> placeholder for empty strings,
> which is the recommended way of handling "nullable" CharFields.
>
> The image attached to the issue demonstrates the issue nicely:
>
>
> 
>
> These rows won't even be clickable.
>
> Options:
>
> 1. Make the existing admin `empty_value_display` option also handle empty
> strings.
> 2. Add a new admin option for empty strings, separate from `None`
> (null=True) cases.
>
> We have PR that's not too far off for option 1.
>
> More to the point I'm in favour of option 1 because:
>
> * We have enough admin options already
> * The empty string is just how text-type fields handle the `null` case.
> (i.e. this should already be the behaviour.)
>
> *Are there any reasons we can't adjust `empty_value_display` to also be
> used for empty strings?*
>
> Original Issue: https://code.djangoproject.com/ticket/28404
> PR: https://github.com/django/django/pull/9391
>
> Thanks for the input all!
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> --
> 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/92b12dbc-ace6-4d72-9234-
> 5563625446b2%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/CAFO84S6Wo193A2G4aGqJo_dpQqGgVRC8RnFTmfy71R1RxrgwiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.