Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been working on a third-party application
that allows overriding the default behavior[0].
The project works by tainting objects retrieved from "sealed"
querysets and having fields descriptors lookup whether or
AFAICT the performance hit is minimal unless you are doing something
slow when logging warnings (e.g. -Walways with a slow I/O py.warnings
handler).
The Python/Django instrumentation simply adds a value to Model._state
and look it up on attribute accesses.
Cheers,
Simon
Le lundi 20 août 2018
In general this sounds like a tremendously useful tool... I'm caused to
wonder, however... what, if any, are the performance impacts?
--
Curtis
On 08/21/2018 08:10 AM, charettes wrote:
Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been working on a
Den 17. aug. 2018 22:07, skrev James Bennett:
>
> If you're basing your understanding on browser support, you're not
> doing XML/XHTML. You're doing "a thing that looks like XHTML and works
> in my browser".
Webstandards has and probably always will be defined by browser support.
That's how the
Making the script less noisy here I commented out the actual work.
(So it didn't function as a test.)
(No comment. )
Corrected version:
```
import sys
from django.db import connection
from django.db.migrations.loader import MigrationLoader
loader = MigrationLoader(connection)
backwards =
Den 20. aug. 2018 11:32, skrev Nils Fredrik Gjerull:
> XML
> materialization of HTML5, and there is also the SGML-inspired version.
I intended to write XML serialization :)
--
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official
Hi all,
Currently when you want a model to be edited from a custom modelform, you
need to make use of that new modelform manually in your create/update views
and admin.
Would it be possible to add a new overridable method in the model to
generate a default modelform ?
Then, default
I'd be -1 on anything that encourages people to use ModelForm with all
fields included by default; that's asking for mass-assignment security
holes.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
Not sure that's what's being suggested here James?
But I'm -1 on this because it's adding more coupling between models and
forms.
Also Jamesie, can't you just subclass in your ModelAdmin to
replace get_form / View classes to replace get_form_class and achieve the
same thing? As far as I
