You write:
"It could still be a vulnerability ... / It could fail to parse ... /
could decide it's invalid - This is all pretty bad..."
I agree - this indeed would be really bad, if it can be used in
malicious ways. But note that the fact that django or an upstream lib
decided to slightly
I also think that your requirements are too specific to be added to
django. You are prolly better suited by creating your own test picking
abstraction for this, e.g. by writing custom test suite aggregates or
using unittest.TestLoader.discover and going into tests of interest by
your own logic
Adding to my last comment:
If you are looking for a more tailored unit testing with low test
pressure and still high reliability - maybe coverage.py can give you
enough code insights to build a tailored test index db to only run
affected tests from current code changes. I am not aware of test
@Uri
May I ask, whats the idea behind running a random subset of tests only?
Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into
thinking everything is ok, but in reality the random test selection did
not catch affected code paths? I mean for tests - its all about
I agree that the official Python docs are well maintained and achieve a
tough goal - the right balance of just replaying basic interface facts
on one side, or being overly prosaic on the other side. Nope, they are
well balanced giving enough of both extremes to get you going, place
repo code
Ah interesting that you mentioned django-stubs. I had good to mediocre
success applying it to my own django apps. It gets the job mostly done
for high level interfaces, but shows rough stub edges as soon as you
have to touch lower interfaces (can only speak for the ORM section in
this regard,
+1 on the idea for better inline docs, would be some relief for IDEs
figuring out a proper interface story boosting dev speed for rarely used
aspects, where currently one would have to search through the prosaic
online docs or end up browsing the django source.
On the other hand I am not
My first reflex to this is -1 for a simple reason:
the persistence layer in django is meant to be db-driven. The upload
logic is transient for that reason, and nothing stops you from creating
a better controlled file upload handling with a model holding those
files before entering your real
+1 from my side for removing oracle support from django itself.
If very low usage + high maintenance burden does not qualify for feature
removal, idk what does - maybe not being supportive at all. Oh wait...
In the end such low usage numbers are prolly better served by a 3rd
party package.
Also -1 from my side.
Imho django should deal with django things, and not with other stuff
that may come handy on top. There are many more VCS than git, and even
with git in particular there are several ways to structure your repo. To
me this should stay a matter of VCS/repo tooling, not
Ah sorry for the fuzz, I read too much into your idea and jumped to the
conclusion, that you want to extend INSTALLED_APPS at runtime.
What you describe here
> INSTALLED_APPS = [
> "django.contrib..."
> "..."
> "myapp.core"
> ]
>
>
Am 21.02.23 um 22:05 schrieb Christian González:
My original question was HOW would I implement this in a "good-practice"
way, by not violating Django's conventions, and showing a way it could
be done clean.
I think thats not really feasible without big restrictions on the apps
and what
Am 21.01.23 um 10:53 schrieb 'Adam Johnson' via Django developers
(Contributions to Django itself):
A Django wrapper would actually be more complicated. You’d need to
understand both the PostgreSQL and Django function docs, and you might
not be sure Django does anything special besides call
Am 19.01.23 um 21:14 schrieb Jason Johns:
the AGE function takes in two timestamps and returns an interval. You
can do this in python by subtracting two date/datetime objects and
getting a timedelta. what would the difference be to kick this out to
the db?
I'd say thats mainly about
We had a similar issue in table views, where users can highly customize
the output (like switching on/off columns, complex filtering and custom
multilevel ordering).
For the ordering issue at hand the solution was to append the pk as n-th
order directive on the queryset, if all previous
> To be clear, "pressure to get the API right on the first shot" is a
> statement of fact about adding APIs to a heavily used project in
> general, not a comment on anything said in this mailing thread. Just
> that in this case there's a lot of ways to get the ergonomics wrong.
Yes and I think
I tend to believe the opposite is true. Django was/is a successor in its
field, because it offers an "out-of-the-box" or "batteries included"
experience. Subsequently parts were shaped as needed for that bigger
picture, e.g. the ORM became what it is today.
Does anyone still remember django
Am 27.11.22 um 13:51 schrieb Raphael G:
So my ask here: how do people feel about moving forward with this
limited scope? Previous discussions talked about wanting a larger scope
for it to get merged into core. I believe that instead targetting a
smaller scope means we can at least provide a
Will there *not* be a Django ORM implementation of psycopg3 COPY FROM
when that lands? And, I guess I'll need to figure out when that
lands/would land.
Not automagically, since the ORM does not use COPY internally. The main
ORM parts are pretty generic, thus mostly based on ANSI compliant SQL
> pretty quickly, so if you need testing input (Django 3.2, Postgres) I
> can offer feedback from what I find.
Yes testing would be awesome, esp. for edge cases (test coverage for
default cases is pretty complete for `fast_update` I think).
> Can you tell me more about this statement:
> >
django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com <https://groups.google.com/d/msgid/django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com?utm_medium=email_source=footer>.
--
netzkolchose.de UG (haftungsbeschränkt)
Geschäftsführer: Jörg Breitbart
Handelsreg
@Ion
Well I am not deep enough into django's ArrayField for postgres to tell,
which one is the desired output or right behavioral pattern. For my COPY
FROM rewrite I simply tested several edge cases and tried to get as
close as possible to ArrayField.
From postgres side of things the
o-developers/bad3435e-1299-4b1d-b701-7881e111ec90n%40googlegroups.com?utm_medium=email_source=footer>.
--
netzkolchose.de UG (haftungsbeschränkt)
Geschäftsführer: Jörg Breitbart
Handelsregister: HRB 504791 Amtsgericht Jena
Steuer-Nr.: 161/115/07450
USt-IdNr.: DE268234065
--
You received this messa
@Aaron
Oh well, if anecdotal personal evidence counts for you - here is mine:
Working here since 2008 with Django in tons of projects in different
positions. The project sizes were from small websites to big API-driven
SPA cluster installations (with and w'o DRF). Ofc it is not all rainbows
Hi there,
I dont quite understand where the sudden fuzz about this comes from. I
want to point out a few things, before going down the rabbit hole of
competing high level interfaces, that ValidatedModel/UnvalidatedModel
would introduce:
- Django offers all validation needs as building
Looks to me like being carried forward from the very first metaclass
``MediaDefiningClass``, which happens to be defined in django.forms.widgets.
Should be fixable by explicitly adding a __module__ notion to type().
Not sure though if it is worth additional code just for the sake of
pretty
> Can Django have a RealField that automatically does the cast?
I dont think it is a good idea to go that route in django and add that
as a standard django field, mainly for these reasons:
- FloatField happens to align correctly between pythons only "native"
float type and the chosen db
Well from my own habits to use .get() only for unique filtering (>80% on
pks only) I also see some benefit of a .get_or_none() variant - it would
stop writing those exception handler wrappers over and over halfway
during project realization. A ready-to-go official way would reduce that
to a
40googlegroups.com?utm_medium=email_source=footer>.
--
netzkolchose.de UG (haftungsbeschränkt)
Geschäftsführer: Jörg Breitbart
Handelsregister: HRB 504791 Amtsgericht Jena
Steuer-Nr.: 161/115/07450
USt-IdNr.: DE268234065
--
You received this message because you are subscribed to the Google
I somewhat second what Adrian wrote:
- try-except handling seems to be the most idiomatic way to me
- a flag altering API behavior as .get(..., raises=False) might come
handy, and to avoid naming collisions in arguments this could also be
shaped as a separate get_or_none() method - but: I
How can it be complicated ? I thought it's just something like
getattr(MyModel, field_name) to get value and
model._meta.get_field(unique_field) to get the field instance..
Where can I find explanation for what you mean? and where can I find the
PK code you're referring to?
Field updates
Imho the pk field being treated special by bulk_update (as the only
record filter predicate, non updatable) comes from one simple idea -
stable object identity during the updates. For an ORM proper object
identification is rather important to not mix things up, shifting
identities might create
to django itself.
Cheers,
Jerch
Am 29.04.22 um 09:34 schrieb Jörg Breitbart:
Have found workarounds for older db engines, which makes the more
demanding version requirements from above obsolete. Db support with
these workaround would be:
- SQLite 3.15+ (should work with Python 3.7+ installer
Have found workarounds for older db engines, which makes the more
demanding version requirements from above obsolete. Db support with
these workaround would be:
- SQLite 3.15+ (should work with Python 3.7+ installer, Ubuntu 18 LTS)
- MySQL 5.7+ (older versions should work too, not tested)
The
Some findings/ideas on possible expression field support:
The SQL standard requires, that within a single UPDATE command the
column ordering does not matter. This effectively means, that the RHS of
the SET clause operates on old record values, while LHS gets the new
values, which dont
@Mariusz
Thx for the update on the db support roadmap, helps alot to get things
into perspective.
@expression support
After a few more tests it turns out, that expression support prolly can
be saved exactly as it is by a combination of the current CASE chaining
with the VALUES table. At
@Florian
Thx for your response.
Looking through the release notes and the listed databases I find these
version requirements:
- PostgreSQL 10+
- MariaDB 10.2+
- MySQL 5.7+
- Oracle 19c+
- SQLite 3.9.0+
Compared to the UPDATE FROM VALUES pattern requirements:
- MariaDB 10.3.3+
- MySQL 8.0.19+
Hi there,
I have recently tried to tackle the known performance issues of
bulk_update. For more context plz see the original thread:
https://code.djangoproject.com/ticket/31202
In another issue we kinda ended up at the same idea again for a
different reason
38 matches
Mail list logo
