Re: Filterable subqueries ...

[charettes]

Hey Bern,

> And there seems no way in Django currently to do such a simple breakout 
SELECT wrapper with Subqueries that I can find.

Right, there's no public API to perform the pushdown but what you are 
looking for is really
similar to what QuerySet.aggregate() (through 
sql.query.Query.get_aggregation) does when
the query happens to use .distinct(). I think that removing the 
`contains_aggregate` checks
in .aggregate()[0] could actually make it work out of the box with an 
aggregate(F(), RowNumber)
and the check can probably be worked around by passing subclasses of F and 
RowNumber
that set `contains_aggregate = True` during `resolve_expression` when 
passed `is_summary=True`.

Note that there have been previous requests for this exact feature[1] and 
by playing around a bit
with Subquery and sql.Query.get_aggregation recently[2] I'm pretty 
confident most of the logic of
the latter could be reused to implement it.

Simon

[0] 
https://github.com/django/django/blob/f976ab1b117574db78d884c94e549a6b8e4c9f9b/django/db/models/query.py#L376-L377
[1] https://code.djangoproject.com/ticket/24462
[2] https://github.com/django/django/pull/11062

Le jeudi 14 mars 2019 20:18:59 UTC-4, Bernd Wechner a écrit :
>
> Josh,
>
> Thanks very much for your contribution. Yes it is not concise, but I did 
> hope it is clear. Alas there is a contest between a well presented, well 
> researched, and complete question and a concise one. Sometimes the two 
> don't reconcile themselves well I admit.
>
> Your supposition is almost right though:
>
>1. It relates to more to a problem that DISTINCT and INNER JOIN 
>produce with Window functions. If you want DISTINCT tuples on a JOINed 
> pair 
>of tables that is fine, but the minute you put a window function in 
> because 
>each tuple gains a unique value before the DISTINCT is applied DISTINCT is 
>rendered functionally useless.
>2. The only fix to that is to force DISTINCT to apply before the 
>window functions are added (i.e. before annotating).
>3. Django seems not to have a way to do that, bar RAW SQL. And I would 
>argue it should.
>
> To paraphrase your example and ignoring JOINS, in the interest of 
> simplicity and brevity:
>
> In this query if multiple tuples that match the WHERE share the same value 
> of field1 then rows in the output are duplicated.
>
>SELECT t.field1
>FROM T t
>WHERE t.field2 like "%x%"
>
> In this query:
>
>SELECT DISTINCT t.field1
>FROM T t
>WHERE t.field2 like "%x%"
>
> the duplication is avoided. But in this query:
>
>SELECT DISTINCT t.field1, row_number(t.other, 1) over ( .. ) as wrownum
>FROM T t
>WHERE t.field2 like "%x%"
>
> The duplication is maintained. That is because each row receives a unique 
> value of wrownum, and DISTINCT is applied to the result! The way to fix 
> this is:
>
> SELECT t.field1, row_number(t.other, 1) over ( .. ) as wrownum
> FROM (
> SELECT DISTINCT t.field1
> FROM T t
> WHERE t.field2 like "%x%"
> ) inn
>
> And there seems no way in Django currently to do such a simple breakout 
> SELECT wrapper with Subqueries that I can find. 
>
> As an aside, if t.field1 is an object id, the above example actually 
> causes no problems, but when you do a join to any that that T has a ToMany 
> relationship with, then this problem emerged which is where I find it. I 
> get duplicate tuples with the same id because the LIKE matches more than 
> one of the related objects. That complicates the queries a little and is 
> well presented on StackOverflow.
>
> My concern is it's not possible and would be if we supported perhaps a new 
> argument on filters like Wrap which if true wraps the SQL in a new Select. 
> BUt I'm not 100% sure there isn't an existing Django ORM option, I am just 
> at this point deeply suspicious there isn't one.
>
> Your example below BTW is also a fine use case, and similarly not 
> supported currently  in the ORM I fear. Unless (and I hope) I am mistaken.
>
> Kind regards,
>
> Bernd.
>
>
> On Tuesday, 12 March 2019 20:29:16 UTC+11, Josh Smeaton wrote:
>>
>> With regard to the stunning silence you're witnessing, it's my guess that 
>> you haven't made yourself clear enough in a concise way. The stackoverflow 
>> post is large, and doesn't point out what's missing very clearly.
>>
>> What is the SQL you want?
>>
>> What is the SQL you're getting, and what is the queryset you're 
>> constructing?
>>
>> I **think** what you're trying to get to is this:
>>
>> SELECT * FROM ( 
>>SELECT
>>t.field,
>>lag(t.other, 1) over ( .. ) as wlag
>>FROM T t
>>WHERE t.field = 1
>> ) inn
>> WHERE wlag = 3;
>>
>>
>> That is, you want to be able to filter on annotations without copying the 
>> annotation into the WHERE clause by wrapping with an outer query that does 
>> the filtering. Is that correct?
>>
>> On Thursday, 28 February 2019 23:27:07 UTC+11, Bernd Wechner wrote:
>>>
>>> I have a 

Re: Filterable subqueries ...

[Bernd Wechner]

Josh,

Thanks very much for your contribution. Yes it is not concise, but I did 
hope it is clear. Alas there is a contest between a well presented, well 
researched, and complete question and a concise one. Sometimes the two 
don't reconcile themselves well I admit.

Your supposition is almost right though:

   1. It relates to more to a problem that DISTINCT and INNER JOIN produce 
   with Window functions. If you want DISTINCT tuples on a JOINed pair of 
   tables that is fine, but the minute you put a window function in because 
   each tuple gains a unique value before the DISTINCT is applied DISTINCT is 
   rendered functionally useless.
   2. The only fix to that is to force DISTINCT to apply before the window 
   functions are added (i.e. before annotating).
   3. Django seems not to have a way to do that, bar RAW SQL. And I would 
   argue it should.
   
To paraphrase your example and ignoring JOINS, in the interest of 
simplicity and brevity:

In this query if multiple tuples that match the WHERE share the same value 
of field1 then rows in the output are duplicated.

   SELECT t.field1
   FROM T t
   WHERE t.field2 like "%x%"

In this query:

   SELECT DISTINCT t.field1
   FROM T t
   WHERE t.field2 like "%x%"

the duplication is avoided. But in this query:

   SELECT DISTINCT t.field1, row_number(t.other, 1) over ( .. ) as wrownum
   FROM T t
   WHERE t.field2 like "%x%"

The duplication is maintained. That is because each row receives a unique 
value of wrownum, and DISTINCT is applied to the result! The way to fix 
this is:

SELECT t.field1, row_number(t.other, 1) over ( .. ) as wrownum
FROM (
SELECT DISTINCT t.field1
FROM T t
WHERE t.field2 like "%x%"
) inn

And there seems no way in Django currently to do such a simple breakout 
SELECT wrapper with Subqueries that I can find. 

As an aside, if t.field1 is an object id, the above example actually causes 
no problems, but when you do a join to any that that T has a ToMany 
relationship with, then this problem emerged which is where I find it. I 
get duplicate tuples with the same id because the LIKE matches more than 
one of the related objects. That complicates the queries a little and is 
well presented on StackOverflow.

My concern is it's not possible and would be if we supported perhaps a new 
argument on filters like Wrap which if true wraps the SQL in a new Select. 
BUt I'm not 100% sure there isn't an existing Django ORM option, I am just 
at this point deeply suspicious there isn't one.

Your example below BTW is also a fine use case, and similarly not supported 
currently  in the ORM I fear. Unless (and I hope) I am mistaken.

Kind regards,

Bernd.


On Tuesday, 12 March 2019 20:29:16 UTC+11, Josh Smeaton wrote:
>
> With regard to the stunning silence you're witnessing, it's my guess that 
> you haven't made yourself clear enough in a concise way. The stackoverflow 
> post is large, and doesn't point out what's missing very clearly.
>
> What is the SQL you want?
>
> What is the SQL you're getting, and what is the queryset you're 
> constructing?
>
> I **think** what you're trying to get to is this:
>
> SELECT * FROM ( 
>SELECT
>t.field,
>lag(t.other, 1) over ( .. ) as wlag
>FROM T t
>WHERE t.field = 1
> ) inn
> WHERE wlag = 3;
>
>
> That is, you want to be able to filter on annotations without copying the 
> annotation into the WHERE clause by wrapping with an outer query that does 
> the filtering. Is that correct?
>
> On Thursday, 28 February 2019 23:27:07 UTC+11, Bernd Wechner wrote:
>>
>> I have a problem I've only been able to solvewhich bugs me. I've posted 
>> on the Django users list (to stunning silence) and on stackoverflow:
>>
>>
>> https://stackoverflow.com/questions/54388936/using-django-window-functions-on-a-filtered-queryset
>>
>> to comparable silence.  I'm rather convinced this can't be done in Django 
>> without raw SQL and that it is an integral part of Window function utility 
>> so I'd like to propose a native ORM based solution to the problem.
>>
>> To understand the context it will be necessary to read the post on Stack 
>> Overflow above, there seems little point in copying the text here. 
>>
>> The proposal though is simple enough. It is that 
>> django.db.models.Subquery support the methods that 
>> django.db.models.QuerySet does, specifically SQL constructing methods like 
>> annotate() and filter() - I'm sure there are more. 
>>
>> The idea is to make easily available a way of selecting from a subquery 
>> such that something akin to:
>>
>> SQ = Subquery(model.objects.filter(...))   
>>
>> produces SQL in the form:
>>
>> SELECT ... FROM model WHERE ...
>>
>> and now:
>>
>> Q = SQ.filter(---)
>>
>> would produce SQL in the form:
>>
>> SELECT * FROM (SELECT ... FROM model WHERE ...) AS SQ WHERE ---
>>
>> Essentially permitting us to filter on the results of a Subquery. 
>>
>> Again, this is crucial when using Window functions like LAG and LEAD 

Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

[Diego Lima]

On Thursday, March 14, 2019 at 7:09:23 PM UTC-3, Curtis Maloney wrote:
>
> Be aware that outside of the ponzi-scheme laden world of 
> cryptocurrencies, "crypto" is short for "cryptography" ; be careful to

ensure your audience knows which you mean :)


Noted! 

This sounds like an interesting and potentially very popular project.
>

Awesome! I'm glad you think that.
 

> However, AIUI Django's GSoC projects should involve development of 
> Django itself. 


So my idea falls out of scope? Did I make a mistake?

I think I didn't. Check this out:

[image: Screenshot from 2019-03-14 19-50-03.png]

Is there a reason why your project could not remain a 3rd party library? 
> This would allow it to develop and release at a pace independently of 
> Django's release cadence. 
>

Originally, this idea is a library which supplements or add new features to 
Django in order to ease the development. This category already includes 
tools such as South and Django Debug Toolbar, as stated in Django's GSoC 
page. 

As such, this project *could* remain a 3rd party library. Right?



Alternatively (and free-thinking-ly), one "variant" of this proposal would 
be to make some sort of database blockchain-enabled backend. So, today you 
have postgres, mysql, sqlite and oracle backends. With this project, there 
would be a fifth one: custom blockchain backend. You could store your data 
seamlessly, through your models, using this backend.

The schedule would be very different, though. 

Also, it's probably better not to make a backend out of it, but a model 
meta option instead.

As of now, I prefer the original idea.

-- 
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/f39ec232-5004-4b2a-82e6-be9dbed21043%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

[Curtis Maloney]

On 3/15/19 6:42 AM, Diego Lima wrote:

*Introduction*

These days, every single living being has heard of Bitcoin. Some of 
those know that Bitcoin is a cryptocurrency (crypto for short) and, 
within those, a few know that it runs on top of a technology called 
Blockchain.


Be aware that outside of the ponzi-scheme laden world of 
cryptocurrencies, "crypto" is short for "cryptography" ; be careful to 
ensure your audience knows which you mean :)



*My proposal is...*


to develop a library to supplement or support the development of django 
applications with blockchain integration.


My success indicator is whether I have made it easy for anyone to store 
and retrieve information on the blockchain inside their Django code.


This sounds like an interesting and potentially very popular project.

However, AIUI Django's GSoC projects should involve development of 
Django itself.


Is there a reason why your project could not remain a 3rd party library?
This would allow it to develop and release at a pace independently of 
Django's release cadence.


--
Curtis

--
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/0e744ce5-714c-d7c4-7677-45d410e2750d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

GSoC 2019 proposal - Easy Ethereum Blockchain integration

[Diego Lima]

*Introduction*


These days, every single living being has heard of Bitcoin. Some of those 
know that Bitcoin is a cryptocurrency (crypto for short) and, within those, 
a few know that it runs on top of a technology called Blockchain.


This technology has boomed just alongside Bitcoin since the year 2008, and 
it is being used in many different sectors of society (having numerous 
examples worldwide): finance, industry, healthcare, government.


It has existed for some years now, and there are many different 
blockchains. For crypto, their role is to provide a *descentralized* 
framework upon which one can execute monetary transactions in a *verifiable*, 
*irreversible* manner. But some of those blockchains provide extra 
funcionality: something known as a *smart contract*.

Basically, a smart contract is some computer code that runs on top of a 
blockchain (thus, it has cryptography-enabled *credibility*) that enforces 
some rules to be obeyed by the involved parties.

The first blockchain smart contracts were introduced by Ethereum platform. 
As stated in their website :

*Ethereum is a decentralized platform that runs smart contracts: 
applications that run exactly as programmed without any possibility of 
downtime, censorship, fraud or third-party interference. *

*These apps run on a custom built blockchain, an enormously powerful shared 
global infrastructure that can move value around and represent the 
ownership of property.*


In other words, blockchain is a protocol for users to build systems which 
need to agree on something. And this thing may be just as simple as a 
monetary transaction, or as complex as a government. *So, having a way to 
easily interact with this technology can enable a whole new set of 
applications.*


*My proposal is...*

to develop a library to supplement or support the development of django 
applications with blockchain integration.

My success indicator is whether I have made it easy for anyone to store and 
retrieve information on the blockchain inside their Django code. 


*Prototype*

I already have a working prototype 
. It consists of a simple 
RESTFul API, and it is part of a side project I was working on: a generic 
architecture where the users can channel some input to a fast or robust 
machine to do some processing. The RESTful API was right in the middle, 
connecting the user device and the robust machine. 

The example I have built goes like this: 

   1. The user generates a drawn numerical digit through an android/iOS 
   application, and sends it to the Django API along with his/her ethereum 
   wallet address.
   2. The Django API verifies whether the user has paid a small fee. This 
   verification is done by checking if the user has sent a certain ETH amount 
   to a smart contract I have designed and launched (in a private network).
   3. The users who have paid this fee have their input processed by my 
   machine. I have set up a convolutional neural network which will recognize 
   single handwritten digits in images. The user then receives the processing 
   result.

The idea for this architecture is to be modular and easily extendable for 
any purpose: signal processing, image processing, data crunching...

If my proposal is accepted, I will be open to work on it and do my best, 
and I expect to learn a lot with my mentor.  I also expect to hear 
suggestions on how to lead this proposal to the most useful functionality.


*Schedule*

Since I already have a working propotype, a good week can be spent on 
discussing the existing work, the general implementation design and scope.

The following weeks will be spent building, writing tests and documenting.

The last week should be spent building some working demo.


*About me*

I'm a computer engineering student in Brazil, and I have 3 (soon to be 4) 
years of experience working with Django. Some big projects I have worked on 
are PMAQ  and SMART 
, which are related to health quality 
data collection (all over the country) and business intelligence.


-- 
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/11e3174e-a2c3-4e37-a1df-2bd24b1ba850%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Tobias McNulty]

I want to qualify this by saying that personally I've always thought of
(and likely will continue to think of) model objects as a snapshot of
what's in the database, and use the more explicit queryset.update() when
that snapshot is NOT what I want to save back to the database. So I may be
somewhat biased against this idea to start with. :)

That said, as Simon mentioned, don't we already effectively support this?

>>> from django.db import connection
>>> from food.models import Food
>>> f = Food.objects.only('pk').first()
>>> f.name = 'foo'
>>> f.save()
>>> connection.queries
[{'sql': 'SELECT "food_food"."id" FROM "food_food" ORDER BY
"food_food"."food_code" ASC LIMIT 1', 'time': '0.003'}, {'sql': 'UPDATE
"food_food" SET "name" = \'foo\' WHERE "food_food"."id" = 5542', 'time':
'0.010'}]

(For the record, this model has many more fields.)

Of course, if you need other fields to calculate whatever needs to be saved
back to the DB, you should add them to .only(). But in any case it protects
you from silently losing data by forgetting to include them in
update_fields (at the risk of generating extra queries if you forget to
include them in .only(), but at least you can see those and optimize them
away).

Consider me relatively ambivalent about the idea...perhaps +0 on a Meta- or
save()-level implementation and -0 on a settings-based approach (given the
red flags already raised).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Thu, Mar 14, 2019 at 11:20 AM charettes  wrote:

> +1 to what Adam said. Turning this feature on by default would be
> certainly cause a lot of bugs in application
> expecting a "coherent state" to be persisted on .save().
>
> That would effectively make most of the Form.clean(), Model.clean() and
> DRF serializer logic in charge of
> validating a field value based on another field value useless as another
> process could race to update the
> row to another state unless you've defined database level constraints as
> well.
>
> > ... performance *benefits* of executing smaller UPDATE statements that
> write fewer columns.
>
> FWIW the current .save() logic ignores deferred fields so it's currently
> possible to work around the
> rare cases where updating a large column causes a slow UPDATE query.
>
> > I'm not sure if a global setting is a good idea. Code in third-party
> apps would need to work with both configurations?
>
> Agreed, it feels like a Meta or .save() option would be more appropriate,
> we already have a select_on_save
> option for example which is even more specific than this use case.
>
> At this point I'm not convinced that it's something Django should
> implement internally as it is possible to implement
> an abstract model in charge of tracking "dirty" fields and overriding
> `.save` to make `update_fields` default to it
> as demonstrated by the few existing third-party solutions.
>
> Simon
>
> Le jeudi 14 mars 2019 09:49:59 UTC-4, Tim Graham a écrit :
>>
>> I'm not sure if a global setting is a good idea. Code in third-party apps
>> would need to work with both configurations?
>>
>> On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>>>
>>> I agree with this:
>>>
>>> > Therefore it seems like it would be a breaking change which is hard to
>>> communicate to users, a complicated situation.
>>>
>>> This is why I'm recommending that this behavior be opt-in via a Django
>>> setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers
>>> would then need to make a determination for themselves whether or not to
>>> enable it.
>>>
>>> Adam is right to point out an edge case where this behavior could lead
>>> to subtle bugs. Not surprisingly, it's related to concurrency (which is
>>> where subtle bugs tend to live)! In response, I would point out that the
>>> whole point of this proposal is to address a *different* edge case,
>>> also related to concurrency, which I personally believe is more common,
>>> though it's admittedly hard to know without a lot of empirical data.
>>> (Actually it's also present in the scenario Adam describes, and he
>>> addresses this: "Sure there's a race condition and the results of either
>>> process 1 or 2 can be lost.")
>>>
>>> From the perspective of an application developer, if this functionality
>>> were available to me, I'd want to look at the code and ask myself this
>>> question: which is more work?
>>>
>>>- Are there lots of places where the code is setting a small number
>>>of attributes and calling save() without update_fields, where concurrent
>>>requests (or background jobs) could override each other's writes and user
>>>data could be lost? Should I leave SAVE_UPDATE_DIRTY_FIELDS_ONLY
>>>*disabled*, enumerate these code paths and add update_fields to all
>>>of them?
>>>- Are there lots of places where the code is setting model
>>>attributes whose values are derived from a combination of other 
>>> attributes,
>>>not all of 

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[charettes]

+1 to what Adam said. Turning this feature on by default would be certainly 
cause a lot of bugs in application
expecting a "coherent state" to be persisted on .save().

That would effectively make most of the Form.clean(), Model.clean() and DRF 
serializer logic in charge of
validating a field value based on another field value useless as another 
process could race to update the
row to another state unless you've defined database level constraints as 
well.

> ... performance *benefits* of executing smaller UPDATE statements that 
write fewer columns. 

FWIW the current .save() logic ignores deferred fields so it's currently 
possible to work around the
rare cases where updating a large column causes a slow UPDATE query.

> I'm not sure if a global setting is a good idea. Code in third-party apps 
would need to work with both configurations?

Agreed, it feels like a Meta or .save() option would be more appropriate, 
we already have a select_on_save
option for example which is even more specific than this use case.

At this point I'm not convinced that it's something Django should implement 
internally as it is possible to implement
an abstract model in charge of tracking "dirty" fields and overriding 
`.save` to make `update_fields` default to it
as demonstrated by the few existing third-party solutions.

Simon

Le jeudi 14 mars 2019 09:49:59 UTC-4, Tim Graham a écrit :
>
> I'm not sure if a global setting is a good idea. Code in third-party apps 
> would need to work with both configurations?
>
> On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>>
>> I agree with this:
>>
>> > Therefore it seems like it would be a breaking change which is hard to 
>> communicate to users, a complicated situation.
>>
>> This is why I'm recommending that this behavior be opt-in via a Django 
>> setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers 
>> would then need to make a determination for themselves whether or not to 
>> enable it.
>>
>> Adam is right to point out an edge case where this behavior could lead to 
>> subtle bugs. Not surprisingly, it's related to concurrency (which is where 
>> subtle bugs tend to live)! In response, I would point out that the whole 
>> point of this proposal is to address a *different* edge case, also 
>> related to concurrency, which I personally believe is more common, though 
>> it's admittedly hard to know without a lot of empirical data. (Actually 
>> it's also present in the scenario Adam describes, and he addresses this: 
>> "Sure there's a race condition and the results of either process 1 or 2 can 
>> be lost.")
>>
>> From the perspective of an application developer, if this functionality 
>> were available to me, I'd want to look at the code and ask myself this 
>> question: which is more work?
>>
>>- Are there lots of places where the code is setting a small number 
>>of attributes and calling save() without update_fields, where concurrent 
>>requests (or background jobs) could override each other's writes and user 
>>data could be lost? Should I leave SAVE_UPDATE_DIRTY_FIELDS_ONLY 
>>*disabled*, enumerate these code paths and add update_fields to all 
>>of them?
>>- Are there lots of places where the code is setting model attributes 
>>whose values are derived from a combination of other attributes, not all 
>> of 
>>which are set? Should I *enable* SAVE_UPDATE_DIRTY_FIELDS_ONLY, 
>>enumerate these code paths and wrap them in select_for_update to ensure 
>> the 
>>data doesn't get into an inconsistent state?
>>
>>
>> On Monday, January 28, 2019 at 8:00:21 AM UTC-6, Daniel Tao wrote:
>>>
>>> Hi!
>>>
>>> This is my first post on this list. I recently left a comment on #27017 
>>>  requesting to 
>>> re-open the topic of only saving dirty fields in save(). Tim Graham 
>>> helpfully directed to #4102  
>>> and 
>>> advised that I make the proposal on the dev mailing list, so that's what 
>>> I'm doing :)
>>>
>>> I've gone through the history of #4102 and taken notes on the challenges 
>>> that arose when this was first attempted 12 years ago (!). The TL;DR is 
>>> that, while there were indeed quite a few complications, I don't see 
>>> anything that came up that should be considered a flat-out showstopper. 
>>> Rather, what happened was that at about the 69th comment 
>>> , back in 2012, 
>>> the conversation shifted as Matt Long made this observation:
>>>
>>> what started as a simple opt-in feature request of adding a field 
 white-list to the Model's save function morphed into a complicated dirty 
 flag approach that obviously has many edge cases and performance 
 implications given that this ticket has been open for 5 years now
>>>
>>>
>>> From here it seems things progressed towards the current solution of 
>>> supporting the 

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Tim Graham]

I'm not sure if a global setting is a good idea. Code in third-party apps 
would need to work with both configurations?

On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>
> I agree with this:
>
> > Therefore it seems like it would be a breaking change which is hard to 
> communicate to users, a complicated situation.
>
> This is why I'm recommending that this behavior be opt-in via a Django 
> setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers 
> would then need to make a determination for themselves whether or not to 
> enable it.
>
> Adam is right to point out an edge case where this behavior could lead to 
> subtle bugs. Not surprisingly, it's related to concurrency (which is where 
> subtle bugs tend to live)! In response, I would point out that the whole 
> point of this proposal is to address a *different* edge case, also 
> related to concurrency, which I personally believe is more common, though 
> it's admittedly hard to know without a lot of empirical data. (Actually 
> it's also present in the scenario Adam describes, and he addresses this: 
> "Sure there's a race condition and the results of either process 1 or 2 can 
> be lost.")
>
> From the perspective of an application developer, if this functionality 
> were available to me, I'd want to look at the code and ask myself this 
> question: which is more work?
>
>- Are there lots of places where the code is setting a small number of 
>attributes and calling save() without update_fields, where concurrent 
>requests (or background jobs) could override each other's writes and user 
>data could be lost? Should I leave SAVE_UPDATE_DIRTY_FIELDS_ONLY 
>*disabled*, enumerate these code paths and add update_fields to all of 
>them?
>- Are there lots of places where the code is setting model attributes 
>whose values are derived from a combination of other attributes, not all 
> of 
>which are set? Should I *enable* SAVE_UPDATE_DIRTY_FIELDS_ONLY, 
>enumerate these code paths and wrap them in select_for_update to ensure 
> the 
>data doesn't get into an inconsistent state?
>
>
> On Monday, January 28, 2019 at 8:00:21 AM UTC-6, Daniel Tao wrote:
>>
>> Hi!
>>
>> This is my first post on this list. I recently left a comment on #27017 
>>  requesting to 
>> re-open the topic of only saving dirty fields in save(). Tim Graham 
>> helpfully directed to #4102  and 
>> advised that I make the proposal on the dev mailing list, so that's what 
>> I'm doing :)
>>
>> I've gone through the history of #4102 and taken notes on the challenges 
>> that arose when this was first attempted 12 years ago (!). The TL;DR is 
>> that, while there were indeed quite a few complications, I don't see 
>> anything that came up that should be considered a flat-out showstopper. 
>> Rather, what happened was that at about the 69th comment 
>> , back in 2012, 
>> the conversation shifted as Matt Long made this observation:
>>
>> what started as a simple opt-in feature request of adding a field 
>>> white-list to the Model's save function morphed into a complicated dirty 
>>> flag approach that obviously has many edge cases and performance 
>>> implications given that this ticket has been open for 5 years now
>>
>>
>> From here it seems things progressed towards the current solution of 
>> supporting the update_fields argument, and that's where things ended. I 
>> would like to point out that Matt did *not* advocate for completely 
>> abandoning all efforts to support dirty field tracking; to the contrary, in 
>> the same comment he said this (emphasis mine):
>>
>> Clearly some people feel differently and favor the dirty flag approach 
>>> for a more hands-off approach. As such, I propose adding support for *both 
>>> methods*
>>
>>
>> With that in mind, I believe it's worth re-opening this discussion. For a 
>> fairly lengthy justification, see my aforementioned comment on #27017 
>> . I'll copy the 
>> effective TL;DR of the proposal here for convenience:
>>
>> In my opinion Django could make most code bases inherently more resilient 
>>> against latent race conditions by implementing some form of dirty field 
>>> tracking and effectively providing the functionality of update_fields 
>>> automatically. I would like to propose a new setting, something like 
>>> SAVE_UPDATE_DIRTY_FIELDS_ONLY, to change the ORM's default behavior so 
>>> that calls to Model.save() only update the fields that have been set on 
>>> the model instance. Naturally for backwards compatibility this setting 
>>> would be False by default.
>>
>>
>> As for the concerns that were raised when this was first attempted, I 
>> will now attempt to summarize what I found along with, in most cases, a bit 
>> of editorializing from me.
>>

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Daniel Tao]

I agree with this:

> Therefore it seems like it would be a breaking change which is hard to 
communicate to users, a complicated situation.

This is why I'm recommending that this behavior be opt-in via a Django 
setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers would 
then need to make a determination for themselves whether or not to enable 
it.

Adam is right to point out an edge case where this behavior could lead to 
subtle bugs. Not surprisingly, it's related to concurrency (which is where 
subtle bugs tend to live)! In response, I would point out that the whole 
point of this proposal is to address a *different* edge case, also related 
to concurrency, which I personally believe is more common, though it's 
admittedly hard to know without a lot of empirical data. (Actually it's 
also present in the scenario Adam describes, and he addresses this: "Sure 
there's a race condition and the results of either process 1 or 2 can be 
lost.")

>From the perspective of an application developer, if this functionality 
were available to me, I'd want to look at the code and ask myself this 
question: which is more work?

   - Are there lots of places where the code is setting a small number of 
   attributes and calling save() without update_fields, where concurrent 
   requests (or background jobs) could override each other's writes and user 
   data could be lost? Should I leave SAVE_UPDATE_DIRTY_FIELDS_ONLY 
   *disabled*, enumerate these code paths and add update_fields to all of 
   them?
   - Are there lots of places where the code is setting model attributes 
   whose values are derived from a combination of other attributes, not all of 
   which are set? Should I *enable* SAVE_UPDATE_DIRTY_FIELDS_ONLY, 
   enumerate these code paths and wrap them in select_for_update to ensure the 
   data doesn't get into an inconsistent state?


On Monday, January 28, 2019 at 8:00:21 AM UTC-6, Daniel Tao wrote:
>
> Hi!
>
> This is my first post on this list. I recently left a comment on #27017 
>  requesting to 
> re-open the topic of only saving dirty fields in save(). Tim Graham 
> helpfully directed to #4102  and 
> advised that I make the proposal on the dev mailing list, so that's what 
> I'm doing :)
>
> I've gone through the history of #4102 and taken notes on the challenges 
> that arose when this was first attempted 12 years ago (!). The TL;DR is 
> that, while there were indeed quite a few complications, I don't see 
> anything that came up that should be considered a flat-out showstopper. 
> Rather, what happened was that at about the 69th comment 
> , back in 2012, 
> the conversation shifted as Matt Long made this observation:
>
> what started as a simple opt-in feature request of adding a field 
>> white-list to the Model's save function morphed into a complicated dirty 
>> flag approach that obviously has many edge cases and performance 
>> implications given that this ticket has been open for 5 years now
>
>
> From here it seems things progressed towards the current solution of 
> supporting the update_fields argument, and that's where things ended. I 
> would like to point out that Matt did *not* advocate for completely 
> abandoning all efforts to support dirty field tracking; to the contrary, in 
> the same comment he said this (emphasis mine):
>
> Clearly some people feel differently and favor the dirty flag approach for 
>> a more hands-off approach. As such, I propose adding support for *both 
>> methods*
>
>
> With that in mind, I believe it's worth re-opening this discussion. For a 
> fairly lengthy justification, see my aforementioned comment on #27017 
> . I'll copy the 
> effective TL;DR of the proposal here for convenience:
>
> In my opinion Django could make most code bases inherently more resilient 
>> against latent race conditions by implementing some form of dirty field 
>> tracking and effectively providing the functionality of update_fields 
>> automatically. I would like to propose a new setting, something like 
>> SAVE_UPDATE_DIRTY_FIELDS_ONLY, to change the ORM's default behavior so 
>> that calls to Model.save() only update the fields that have been set on 
>> the model instance. Naturally for backwards compatibility this setting 
>> would be False by default.
>
>
> As for the concerns that were raised when this was first attempted, I will 
> now attempt to summarize what I found along with, in most cases, a bit of 
> editorializing from me.
>
> Performance
>
> The performance angle was first explored in a comment 
>  that said it 
> "doesn't look good" and provided some benchmarks showing a performance hit 
> from 0.17s to 2.64s for setting an attribute using the timeit 
> 

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Adam Johnson]

I believe there's the opportunity for a subtle bug in applications if
Django moves from its current default behaviour of saving all fields to
saving only dirty fields. Values in a model instance can become "torn"
between two versions by two concurrent processes even though neither wanted
to do this.

Take this model:

class Photo(models.Model):
likes = models.IntegerField()
multiplier = models.IntegerField()
total = models.IntegerField()

Let's say total should always equal likes * multiplier .

Process 1 (which could be a view, management command, celery task, etc.)
increases a Photo's likes:

photo = Photo.objects.get(id=id)
photo.likes += 1
photo.total = photo.likes * photo.multiplier
photo.save()

Process 2 updates a Photo's multiplier:

photo = Photo.objects.get(id=id)
photo.multiplier = new_multiplier
photo.total = photo.likes * photo.multiplier
photo.save()

To avoid problems if these two processes run at once on the same Photo
instance,
transactions or row-level locking with select_for_update() should be used,
so they don't run actually in parallel. These aren't the default in Django
though (I wish ATOMIC_REQUESTS was on by default).

Assuming the application is not using either a transaction or
select_for_update(), current Django does still guarantee that either the
complete state after Process 1 or 2 is in the database, by always writing
back all the fields. That is, no Photo instance can have its total set to
anything but likes * multiplier , since Django's save() sends all fields in
a single UPDATE statement, which is always atomic. Sure there's a race
condition and the results of either process 1 or 2 can be lost, but still
there's a guarantee on the relationship between the values, which
downstream logic might rely on.

Moving to dirty field tracking would break this guarantee. This would
probably cause untold low-level breakage in applications where atomicity
has not been considered. Therefore it seems like it would be a breaking
change which is hard to communicate to users, a complicated situation.

On Wed, 30 Jan 2019 at 13:51, Josh Smeaton  wrote:

> That's a +1 from me. I've certainly hit the bugs you've mentioned before,
> and I can't think of a good reason not to do dirty field tracking,
> especially if it were to be opt in.
>
> Bikeshedding a little bit, rather than having a global setting, I'd rather
> see an option on Options/Meta so that opt in is per-model. On a related
> note, I'd like to see some real world testing of any solution with packages
> that implement polymorphic models.
>
> On Tuesday, 29 January 2019 01:00:21 UTC+11, Daniel Tao wrote:
>>
>> Hi!
>>
>> This is my first post on this list. I recently left a comment on #27017
>>  requesting to
>> re-open the topic of only saving dirty fields in save(). Tim Graham
>> helpfully directed to #4102  and
>> advised that I make the proposal on the dev mailing list, so that's what
>> I'm doing :)
>>
>> I've gone through the history of #4102 and taken notes on the challenges
>> that arose when this was first attempted 12 years ago (!). The TL;DR is
>> that, while there were indeed quite a few complications, I don't see
>> anything that came up that should be considered a flat-out showstopper.
>> Rather, what happened was that at about the 69th comment
>> , back in 2012,
>> the conversation shifted as Matt Long made this observation:
>>
>> what started as a simple opt-in feature request of adding a field
>>> white-list to the Model's save function morphed into a complicated dirty
>>> flag approach that obviously has many edge cases and performance
>>> implications given that this ticket has been open for 5 years now
>>
>>
>> From here it seems things progressed towards the current solution of
>> supporting the update_fields argument, and that's where things ended. I
>> would like to point out that Matt did *not* advocate for completely
>> abandoning all efforts to support dirty field tracking; to the contrary, in
>> the same comment he said this (emphasis mine):
>>
>> Clearly some people feel differently and favor the dirty flag approach
>>> for a more hands-off approach. As such, I propose adding support for *both
>>> methods*
>>
>>
>> With that in mind, I believe it's worth re-opening this discussion. For a
>> fairly lengthy justification, see my aforementioned comment on #27017
>> . I'll copy the
>> effective TL;DR of the proposal here for convenience:
>>
>> In my opinion Django could make most code bases inherently more resilient
>>> against latent race conditions by implementing some form of dirty field
>>> tracking and effectively providing the functionality of update_fields
>>> automatically. I would like to propose a new setting, something like
>>> SAVE_UPDATE_DIRTY_FIELDS_ONLY, to change the ORM's default 

Re: Django include default user registration, forgot password, OTP feature by default with Django libraries

[Adam Johnson]

See also core contributor James Bennett's blog post about his library
django-registration which provides some of these features
https://www.b-list.org/weblog/2018/sep/04/three-dot-oh/

On Wed, 13 Mar 2019 at 20:57, Jani Tiainen  wrote:

> Hi.
>
> ke 13. maalisk. 2019 klo 18.19 parocks 
> kirjoitti:
>
>> I have been working with Django for small clients.
>> One of the feature I would really love to have is
>> 1. Default User Registration feature (without having to fiddle with
>> things like the admin portal)
>>
>
> Registration is not a simple thing. There are quite many ways to make
> registration happen which is the reason that Django doesn't have any
> default implementation for it. You can find several goid 3rd party packages
> that handles different kind of registrations.
>
> Also you may find that some would like to handle registration by Facebook,
> Google account, LDAP and who knows what else there exists.
>
> 2. Forgot password feature
>>
>
> Django has it already. It's called reset password in contrib.auth
>
> 3. OTP for all user registrations by default
>>
>
> OTP like by TOTP, SMS messages, email or USB dongles or some other means?
>
> And don't you want to have it in login rather than just in registration?
>
> Like you see it's not trivial.
>
>
>> Those three are the missing ones from my opinion.
>> If thats included I would say Django will beat most of the frameworks in
>> the market.
>>
>> Looking forward for easy enablement of those 3 features natively into
>> Django.
>> Please consider documenting it in the api atleast.
>>
>> --
>> 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/02b42c58-edb5-4bab-b745-1dc985e264d1%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/CAHn91od53ZUAxBgziRch5SZfqbRrf4fDEgt9cifA0Y5h2SiAwQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM30KjLQZMHkfyhLTqWCM9%2BmcBZMcpUdcMXew4fX%3DGVj5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Development story for CBV FormViews using GET

[Jamesie Pic]

Kyle, is it possible to show the code you are talking about ?

-- 
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/CAC6Op1-DTUOmh-SB6RB48WZnpwOC20D0hp-f%3D%3DOyDX_Vnevm%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Development story for CBV FormViews using GET

[Carsten Fuchs]

Hello,

I'm not a Django contributor, just a user, but please allow me to express my 
opinion that CBVs are an extra layer of functionality that seems to have made 
it into the foreground attention since it was introduced, but I think that that 
is very unfortunate:

CBVs bring not only extra functionality, but also complexity. With that, they 
obscure the three-paths idea that is used in FBVs (no POST data, POST data that 
validates with errors and without). Yes, the three-paths method seems like a 
tedious pattern that must repeatedly be written by hand. But in my opinion, it 
clearly expresses a key concept that is very important for beginners to 
understand, especially as beginners that are new to Django often are new to web 
development as well.
Kyle seems to have experience with web development, but all the more his 
question is a prime example of that issue.
In my opinion, DRY is not above all. I've been using Django for years and have 
never found CBVs attractive but for a narrow range of use cases.

Personally, I think that both in examples, courses and the Django tutorials the 
focus should be on FBVs. Only then and only on this basis should CBVs be 
introduced, with an emphasis on how they emerged from FBVs.

Best regards,
Carsten


Am 14.03.19 um 07:56 schrieb Luke Plant:
> Hi Kyle,
> 
> My take would be this: What does the code look like if you don't use FormView 
> but just write a function view? How does that compare to using a CBV? This 
> may be the simpler method you are missing - if you are finding you are 
> fighting with inherited functionality, just don't inherit it.
> 
> Luke
> 
> 
> On 09/03/2019 03:55, Kye Russell wrote:
>> Hi,
>>
>> Sometimes it is appropriate to for a HTML form to use the GET method for 
>> submission (usually search / filter forms).
>>
>> My impression has always been that in order to build a FormView-based view 
>> that acts on GET data, you have to override a few methods on your class 
>> (which involves understanding how FormView works). Even as someone with a 
>> fairly good understanding of these classes, I sometimes have to reference a 
>> previously-written example to make sure I've got it right.
>>
>> I am aware of the existence of django-filter[0] which takes care of this for 
>> you, however at times I find it hard to justify adding it to a project just 
>> to deal with this.
>>
>> I have the following questions:
>>
>> * Is my understanding of the current process correct, or is there an easier 
>> way that I've missed?
>> * Is this documented anywhere? I looked at the Django 'working with forms' 
>> documentation[1], and whilst it discusses the different scenarios in which 
>> you'd use GET vs POST, it does not seem to discuss implementations in a CBV 
>> context.
>> * Is there enough of a generic use-case where FormView / FormMixin / 
>> ProcessFormView could be altered to support this? Or are there subtleties / 
>> nuances in each implementation that make a generic solution hard to develop?
>>
>> Sorry if this is the wrong avenue to discuss this. I am approaching it from 
>> the position of wanting to alter Django to better support this use case, but 
>> I'm aware that I may have just missed a Blessed method in the docs.
>>
>> Kye
>>
>> [0]: https://github.com/carltongibson/django-filter
>> [1]: https://docs.djangoproject.com/en/2.1/topics/forms/
>>
>>
>> -- 
>> 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/CANK-ykkMtxezA9cHN8jQ_czLn6OYtdDn6JYbjNgASyyqHH-aAw%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/668e083b-d3c1-8a5b-989e-03a0a85d895a%40cantab.net
>  

Re: Development story for CBV FormViews using GET

[Luke Plant]

  
  
Hi Kyle,
My take would be this: What does the code look like if you don't
  use FormView but just write a function view? How does that compare
  to using a CBV? This may be the simpler method you are missing -
  if you are finding you are fighting with inherited functionality,
  just don't inherit it.
Luke


On 09/03/2019 03:55, Kye Russell wrote:


  
  

  
Hi,


Sometimes it is appropriate to for a HTML form to use
  the GET method for submission (usually search / filter
  forms).


My impression has always been that in order to build a
  FormView-based view that acts on GET data, you have to
  override a few methods on your class (which involves
  understanding how FormView works). Even as someone with a
  fairly good understanding of these classes, I sometimes
  have to reference a previously-written example to make
  sure I've got it right.


I am aware of the existence of django-filter[0] which
  takes care of this for you, however at times I find it
  hard to justify adding it to a project just to deal with
  this.



I have the following questions:


* Is my understanding of the current process correct,
  or is there an easier way that I've missed?
* Is this documented anywhere? I looked at the Django
  'working with forms' documentation[1], and whilst it
  discusses the different scenarios in which you'd use GET
  vs POST, it does not seem to discuss implementations in a
  CBV context.

* Is there enough of a generic use-case where FormView
  / FormMixin / ProcessFormView could be altered to support
  this? Or are there subtleties / nuances in each
  implementation that make a generic solution hard to
  develop?


Sorry if this is the wrong avenue to discuss this. I am
  approaching it from the position of wanting to alter
  Django to better support this use case, but I'm aware that
  I may have just missed a Blessed method in the docs.


Kye



[0]: https://github.com/carltongibson/django-filter

[1]: https://docs.djangoproject.com/en/2.1/topics/forms/





  

  
  -- 
  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/CANK-ykkMtxezA9cHN8jQ_czLn6OYtdDn6JYbjNgASyyqHH-aAw%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/668e083b-d3c1-8a5b-989e-03a0a85d895a%40cantab.net.
For more options, visit https://groups.google.com/d/optout.

Re: Support for unittest -k option

[Luke Plant]

  
  
I use `--keepdb` a lot, I never knew there was a shorthand and
  even know I do know wouldn't use it. For things like this I
  usually find it easy to remember the long option. So I'm +1 on
  changing it too, without a new shorthand for `--keepdb`. In the
  keyword usage `-k` must be followed by a keyword, so for people
  who did use it the shorthand, the old usage will break loudly
  which is good.

Luke


On 11/03/2019 15:13, François Freitag
  wrote:


  Hi Django Devs,

https://code.djangoproject.com/ticket/30245 suggests supporting Python
unittest `-k` option, to selectively run tests matching a keyword.

Currently, `-k` is the shorthand for `--keepdb` in Django.
A `--filter` flag was suggested to preserve backward compatibility.
Carlton suggested removing the `-k` option from `--keepdb` and reusing
it for unittest `-k`. That would follow unittest more closely, reduce
user confusion and ease maintenance.

What do you think is best? Do you see other options?

If re-taking the `-k` option for unittest `-k`, should a new shorthand
be introduced for `--keepdb`?

Thanks for your time,
François



  




-- 
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/ffdefe87-33f9-05c6-ee61-30087deee517%40cantab.net.
For more options, visit https://groups.google.com/d/optout.