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_aggr
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 rig
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
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
*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
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
+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 val
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
> communic
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 nee
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
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:
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-devel
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 funct
13 matches
Mail list logo
