Happy to review help as well.
Enjoy your well deserved time off!
Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit :
>
> Hi all.
>
> Short answer is we don't really know, since we never take holidays. 🙂
>
> I though am having a much needed week off from tomorrow, to be back on the
> 1
FWIW there's ungoing work to allow iterator() to use prefetch_related()
which would allow us to lift this restriction.
See
https://groups.google.com/forum/#!searchin/django-developers/iterator$20prefetch%7Csort:date/django-developers/ADgUd6jRvdw/_ZnETNlcAAAJ
Cheers,
Simon
Le jeudi 11 juin 2020
The code could possibly be removed if the PR gets merged in time for 3.2
yes.
Le jeudi 11 juin 2020 09:44:32 UTC-4, 1337 Shadow Hacker a écrit :
>
> Well that's good to know, thank you charettes !
>
> Does that mean that the piece of code from forms that's using "priva
+1 from me as well but I don't think we should add any logic to the
migration framework to handle the transition.
I think the release plan should be something along the following
Phase 1:
- New projects are generated with MODEL_DEFAULT_PK =
'django.db.models.BigAutoField'
- A system check or wa
mary key they use
for their model but I'm not a big fan of baking logic in the migration
framework to treat some fields in a special way.
Simon
Le jeudi 18 juin 2020 10:18:35 UTC-4, charettes a écrit :
>
> +1 from me as well but I don't think we should add any logic to the
&g
Hello Andor,
I think it would make sense to add this feature to Django but I'm not
convinced per-atomic block granularity is the best API to expose this
rarely used pattern. For example, how should this option behave when
nesting atomic block and mixing readonly values or disabling usage of
sa
Thanks for your work so far Tom!
> There is perhaps some scope in the future to make this take a callable
that can figure out the collation per-database. This would be useful for
getting case-insensitive lookups working across all backends, for example.
But I want to keep that out of the scope
own its review and affect its mid-term mergeability.
>>
>
> Yes, it is probably best to extract the operations to another ticket/PR.
>
> On Mon, 20 Jul 2020 at 03:48, charettes wrote:
>
>> Thanks for your work so far Tom!
>>
>> > There is perhaps some scope i
I like the state of your proposed PR Mariusz. It does add one more setting
but it feels like having this configurable project wide will be a plus as
it will allow the ecosystem to rely on it and hopefully make audit of large
Django application a bit easier when having specific hashing requiremen
Hello Gert, that seems a bit surprising to me and was likely not a desired
change.
Could you bisect the exact commit that caused the regression[0]? That would
certainly help determining the action to take here.
Thanks,
Simon
[0]
https://docs.djangoproject.com/en/3.1/internals/contributing/tri
;.
>
> Cheers
>
> On Tue, 4 Aug 2020 at 15:52, charettes wrote:
>
>> Hello Gert, that seems a bit surprising to me and was likely not a
>> desired change.
>>
>> Could you bisect the exact commit that caused the regression[0]? That
>> would certainly h
is
> surprising and buggy at face value: changing the value of an attribute on
> one object should not change the value of that attribute on another!
>
> Alex
>
> On Wed, Aug 5, 2020 at 7:43 AM charettes wrote:
>
>> It was likely overlooked by the patch.
>>
>&
I agree this limitation of `contrib.contenttypes` is a bit unexpected. Not
saying we should lift it but it does seem arbitrary even if having such
large table names could be considered bad practice.
One approach we could take that doesn't involve any migration is to
fallback to hashing of the o
> Suffix-hashing long names like Simon suggests may not be
backwards-compatible.
Could you elaborate on that?
Assuming model names > 100 characters never worked wouldn't only
suffix-hashing model names > 100 characters be backward compatible?
Simon
Le mardi 11 août 2020 à 12:05:46 UTC-4, Sha
I like the idea but I don't feel comfortable vouching for it given my
conflict of interest.
I'll just say that It does feel weird that folks on this list which are the
main active contributors outside of a few members of the currently elected
TB don't have access to basic triaging and reviewing
I'm also a fan of option 3. to require an explicit opt-in or raise an error.
Not a lot of folks are familiar with this requirement imposed by the usage
of DISTINCT and even if Model.Meta.ordering is the most common reason but
unexpected ordering it can also be caused by the dynamic creation of a
If we were to change the update signature from (**updates) to
(updates=None, *, returning=None, **kwargs) the `returning` collision could
be avoided by doing update({"foo": "bar"}, returning=["id", "foo"]) like
Tom is suggesting.
I think that's the best option here if we want to elegantly add s
As Tom said Django 3.2 supports swapping the default primary key of models
so the integer exhaustion part of your suggestion should be addressed
Regarding identity columns support there's already a ticket opened about it
on Trac[0] where you might want to chime in.
Even #30511 if doesn't land i
Hello Nigel,
Through git blame for unify_by_values I figured it was introduced[0] to
deal with an issue during aggregation[1].
Mariusz might be able to provide more context here as I don't have much
knowledge around Oracle cursor cache but it seems you'll have to find
another way to address th
Hello Daniyal,
> I want to move ahead with using the pickle module. However, does it
seem necessary to add support for other serializers ( json / yaml / msgpack
) as well?
I don't think that adding support for configurable serialization is
necessary for this project. Don't get me wrong, I thin
iable would normally
> be included in both the SELECT list and the GROUP BY.
>
> Regards,
> Nigel
>
> On Monday, 5 April 2021 at 15:45:31 UTC+1 charettes wrote:
>
>> Hello Nigel,
>>
>> Through git blame for unify_by_values I figured it was introduced[0] to
&g
Ticket that directed to the mailing list for wider feedback
https://code.djangoproject.com/ticket/32788
---
Can you think of places where this db_for_transaction hook would differ in
any way from what db_for_write returns? That's what Django uses internally
in such instances
1.
https
yErrors)
2. It's just not common enough to warrant an inclusion in Django core.
Every single added feature comes with a maintenance burden cost and risks
introducing bugs when interacting other existing features. This is
particularly true with niche features interacting with complex sy
Hello there,
Partial unique constraints are currently not supported during validation
for reasons described in this ticket[0].
For example (inspired by this Github comment[1]), if you define the
following model
class Article(models.Model):
slug = models.CharField(max_length=100)
delete
> the models to do something without one.
>
> If you have any more hints as to where I should look, thanks again.
> Le mercredi 2 juin 2021 à 00:33:12 UTC+2, charettes a écrit :
>
>> Hello there,
>>
>> Partial unique constraints are currently not support
> Thanks, it clears things a lot.
>
> I'll try my hand at it when I'll have some more time available.
>
> Le jeudi 10 juin 2021 à 06:00:17 UTC+2, charettes a écrit :
>
>> Alright so here's for a few hints about I believe things should be done.
>>
I meant 1. in my previous email where sql.Query.model is allowed to be
None. The tests happen to pass on SQLite, MySQL, and Postgres.
Le mardi 15 juin 2021 à 20:02:28 UTC-4, charettes a écrit :
> FWIW I thought I'd give a timeboxed shot at 2. to make sure I don't send
> yo
gt; Should we still add Q.check() (which will be as you said before), then
> refactor BaseConstraint.validate() to use it?
>
> Le mercredi 16 juin 2021 à 02:04:31 UTC+2, charettes a écrit :
>
>> I meant 1. in my previous email where sql.Query.model is allowed to be
>> None. The t
Hello there,
I confirm that you'll have to adapt get_table_description for each
supported backends to introspect column comments.
It seems that introspection support was considered to be a requirement for
this ticket[0]. Not sure if that means that the inspectdb logic also needs
to be adapted
That's looking great :)
1. Yes and that's expected. If a form/serializer doesn't provide some
fields included in the constraint the database client side of the
validation can't do much about it. It might result in an integrity error
but that's a misuse of the API. I guess a check/runtime warnin
raw SQL when there is a better way to do it (is there?).
> And it doesn't work when used in the Exists as the table is aliased and
> the raw SQL is not.
>
> Do you have any idea how to fix/improve that?
>
> Thanks again!
>
> Le lundi 21 juin 2021 à 18:00:03 UTC+2, charette
;
> https://github.com/Gagaro/django/commit/cfd10066359c175179ae937a287eb9f0240354f1
>
> Le mardi 22 juin 2021 à 16:43:36 UTC+2, charettes a écrit :
>
>> > I don't like using raw SQL when there is a better way to do it (is
>> there?).
>> > And it doesn'
fter
> all.
>
> Le mercredi 7 juillet 2021 à 20:53:23 UTC+2, charettes a écrit :
>
>> Just a small note that I didn't forget about this thread but I was
>> waiting for lookup annotation support to land before focusing on it[0].
>>
>> I guess you could go ahead
I'm also +1
Le mercredi 21 juillet 2021 à 17:21:03 UTC-4, Adam Johnson a écrit :
> +1 I’m in favour of giving Florian the access and necessary training,
> should he want it.
>
> On Wed, 21 Jul 2021 at 10:18, Carlton Gibson wrote:
>
>> Hello Technical Board.
>>
>> Mariusz is working on updating
While addressing the issue is complex and will require quite a bit of work
to solve in a backward-compatible way I believe that it should be feasible
to emit a MultipleMultiValuedJoin(RuntimeWarning) with pointers for
alternatives (e.g. using subqueries) without too much hassle when
aggregation
Hi everyone,
I'm not sure if we're already aware of the issue but it seems that Trac
hasn't published any changes to the Django Updates Google Group[0] since
March 27th while there was clear activity that took place since then[1].
It seems the updates were published over SMTP[2] and I assume so
If you're interested in following the development of the database level
foreign key constraints feature you should CC to #21961 [0]
The latest attempt at implementing them was recently closed due to
inactivity [1]
Cheers,
Simon
[0] https://code.djangoproject.com/ticket/21961
[1] https://github
The main drawback will be that won't be able to take advantage of
setUpTestData to perform costly data creation _once_ for all the tests
attached to the same TestCase.
Splitting the suite per test will likely force setUpTestData to be called
once per process that has at least once one test of t
> Is it necessary to take a base field? Can we not determine the output
field type for some kinds of expression? e.g. F("some_integer_field") + 1
can be assumed to have output field type IntegerField.
It should be possible by simply accessing the `output_field` property of
the provided expressi
That's what I proposed on the ticket but I feel like it felt odd to me, the
setting name does't suggest this is possible and it might be hard to
achieve exact second precious because of float rounding?
In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta support
would be the best opt
Hello Jan,
I'm a bit surprised the `contribute_to_class` approach isn't working but I
remember
there was previous discussions to support passing an `Index` instance to
the `Field.db_index`
option or to allow an `index_class` attribute to be defined on `Field`
subclasses to
determine what kind o
Hello Haki,
I think the optimizations you are suggesting and the way you've implemented
them
make a lot of sense.
I left a few comments on your PR[0] regarding the template tag in charge of
rendering the date hierarchy header in the list view which could benefit
from
the same optimization but e
ributes
to create it's forward descriptor[1].
That gives me hope that it should be feasible to add such a feature
to core if deemed useful without invasive changes.
Cheers,
Simon
[0] https://github.com/charettes/django-seal
[1]
https://github.com/django/django/blob/602481d0c9edb79692955e073
Shai,
`execute_wrapper` can be useful to prevent any queries from
happening at all but I believe there's merit in wanting to
prevent objects retrieved from a queryset from executing ghost
queries during manipulations of the returned `Model` instances
while allowing other unrelated queries to be pe
Hey Matthew,
I could see adding support for F('field')[0:5] being useful and more
intuitive
than using Left/Right/Substr. You should be able to assert the field is
sliceable
(e.g. an instance of CharField/TextField) in the expression returned by
F.__getitem__ (e.g. Left/Right/Substr) resolve_exp
field descriptors would error out.
Cheers,
Simon
P.-S.
While the project might look complex most of the code takes care
of the delicate tasks of replacing fields descriptors once models
are configured which could be significantly simplified if it was
part of Django core.
[0] https://github.com/c
19:34:11 UTC-4, Curtis Maloney a écrit :
>
> 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:
> > Rega
Hello Alex!
Thanks for your work on this project, this is definitely something that I
believe would be useful in Django's core based on the number of times I
implemented a filtered queryset getter on Models.
I'm not totally sold on the API but having an analog of what ForeignObject
is to Forei
Something I would add is that while some third-party apps leverage
swappable models it is not clear how relationships between swappable models
should be dealt with.
This is something we'd have to figure out if `auth.Group` is made swappable
as the default model user model would depend on it.
S
I also dislike bulk_save() for the same reasons.
I feel like bulk_update makes the most of sense given it has a signature
similar to bulk_create where an iterable of model instances must be passed
we're really just performing an update.
To the bulk_update and update is the natural analogous to
While I understand the complexity of 1. I think shipping a version of
Django without
an equivalent inotify replacement such as watchdog could be problematic.
>From my personal experience when using Django's development server in Docker
containers sharing local volumes installing pyinotify resulte
Hello Tobias,
>From my understanding the introduction of chunk_size doest't help here.
The fundamental reason why iterator() cannot be used with
prefetch_related() is that the latter requires a set of model instance to
be materialized to work appropriately which chunk_size doesn't control at
a
Josh, I agree that silently not working is problematic but it has been this
way since prefetch_related() was introduced.
Something to keep in mind as well is that silently turning it on would also
perform P * C extra queries where P is the number of prefetches requested
through prefetch_related
After a bit of work to minimize the cases where sqlparse would be a
required at runtime for SQLite to AddConstraint/RemoveConstraint operations
[0] I came to the conclusion that it would make more sense to make sqlparse
an hard dependency of Django 2.2.
The two reasons backing this conclusions
I don't have a strong opinion on whether or not we should make the switch
but
if the consensus is too move forward with this I'd suggest we wait until
Django
master's branch only supports Python 3.6+.
That would allow us to switch directly to f-strings and avoid doubling the
already
large diff
As I've mentioned on the ticket I've been wishing get(pk) could translate
to get(pk=pk) for a while but I never got to suggest it. Probably because I
didn't feel like adding (pk=...) was really that long. I'd note that most
of the
times I wished this existed was when doing some object manipulation
r. The only
> args that can be used currently are Q() objects (and couples but I think
> it's an issue).
> This proposed design suggestion is to also allow scalar values (strings,
> int, etc) too.
>
>
> On Wednesday, 31 October 2018 18:12:53 UTC, charettes wrote:
>>
FWIW it looks like gettext support issues were addressed a while ago[0]
The main issue standing with existing translations is that they'll need to
be regenerated[1]
which would require a non-trivial amount of coordination between
translation teams I
assume.
Simon
[0] https://bugs.debian.org/cgi
nce has been that it's
>> a stable, well-maintained package over the past few years I've used it.
>>
>> On Sun, 28 Oct 2018 at 05:00, charettes wrote:
>>
>>> After a bit of work to minimize the cases where sqlparse would be a
>>> required at run
I agree with you Tim. +1 from me.
Le lundi 5 novembre 2018 12:03:55 UTC-5, Tim Graham a écrit :
>
> Hi,
>
> A recent bug report [1] brought up the fact that ModelAdmin collects
> actions from superclasses. For example:
>
> class BaseAdmin:
> actions = ['a']
>
> class SubAdmin(BaseAdmin):
>
e refactor of the ORM to
>>> generalise join conditions from key-equality to arbitrary predicates of
>>> which key equality is just one case, at which point Relationship could sit
>>> comfortably as a base class of all the other relations. The assumption that
>>>
Exactly.
Given you should be running tests against a throwaway or at least
non-critical
PostgreSQL cluster anyway I don't think requiring superuser privileges is an
issue.
Simon
Le mardi 6 novembre 2018 18:43:47 UTC-5, Dan Davis a écrit :
>
> So, a developer using PostgreSQL doesn't need superu
1.8/releases/1.8/#testcase-data-setup
[1]
https://docs.djangoproject.com/en/2.1/topics/testing/tools/#django.test.TestCase.setUpTestData
[2]
https://github.com/charettes/django/compare/setuptestdata...charettes:testdata
[3] https://github.com/charettes/django-testdata
[4] https://pypi.org/project/django-test
I haven't tried it out for Oracle yet but Tom Forbes' django-docker-box
seems to make it a not-too-painful process[0]
Simon
[0] https://github.com/orf/django-docker-box#oracle
Le lundi 26 novembre 2018 04:05:41 UTC-5, Johannes Hoppe a écrit :
>
>
> On Monday, November 26, 2018 at 9:49:46 AM UTC
ssmethod
> def setUpTestData(cls):
> cls.data.author = Author.objects.create()
> cls.data.book = cls.author.books.create()
>
> def test_relationship_preserved(self):
> self.assertIs(self.data.book.author, self.data.author)
>
> On Sat, 24 Nov 2018 at 03:29, charet
rying to pickle it? I wouldn't be keen on that overhead. Could you just
> capture any copy exceptions, raise a deprecation warning, and abandon the
> copy for that attribute?
>
> On Saturday, 24 November 2018 14:29:33 UTC+11, charettes wrote:
>>
>> Dear developers,
>
Hey Tobias, thanks for chiming in.
The main motivation behind this package and this core inclusion proposal is
that I've come across a non-negligible number users that were surprised to
find out this was not working automatically and others that completely
stopped using setUpTestData because of
I agree with Tim that this is a slippery slope.
Maybe that adding a ModelFormMixin.get_form_class_options() that returns a
{'fields': self.fields} dict by default and is passed to
modelform_factory(**kwargs)
in get_form_class() would be a good compromise?
Best,
Simon
Le mardi 4 décembre 2018 1
Thanks for taking the time to post here Joshua!
The main reason why I asked to gather feedback from this list is that I'm
not convinced
that the benefits outweighs the additional complexity this will add to the
already quite
loaded update_or_create() signature handling and how the fact a callabl
Hello there,
You should find all you need from the contributing guide[0] but since you
just started using Django it might be hard to contribute until you get more
familiar with the framework.
This mailing list is dedicated to development of Django itself such as
getting feedback for new featur
I agree with Tim, this is a minor change in a contrib app.
I don't think it warrants all the efforts required for a deprecation period
given the large adoption of https in the recent years.
Le mercredi 9 janvier 2019 06:41:25 UTC-5, Tim Graham a écrit :
>
> Adding temporary settings to the defau
would require. Plus since the
argument was only recently introduced it is less likely to silently cause
changes under developers feet.
Simon
Le vendredi 26 octobre 2018 20:12:02 UTC-4, charettes a écrit :
>
> Josh, I agree that silently not working is problematic but it has been
> this
ueries, so even prefetching for the default
> chunk_size of 2000 would be a huge gain in cases where chunk_size isn't
> defined.
>
> On Sun, 13 Jan 2019 at 02:05, charettes >
> wrote:
>
>> Replying to my concerns about the P * C queries.
>>
>> Throwing that i
To echo my comments on the PR I don't like the idea of relaying args and
kwargs to filter()
as it I think it adds little value considering it paints us in a corner
with regards to future
count()/exists() API change.
For example if we ever want to add `distinct` kwarg and fields arg passing
to .
+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
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
I can be a quite useful option when mergers have to perform small typos and
code style tweaks before a merge.
I'm not sure it's worth documenting given it's the default value though.
Simon
Le dimanche 17 mars 2019 15:17:32 UTC-4, Adam Johnson a écrit :
>
> 3. I believe I’ve seen Tim use the ma
I was and and I'm still bugged by how black decided to go for double quotes
instead of single ones. Even if it's backed some valid arguments it left
all the projects following PEP 8's recommendations over the years with this
git blaming loss trade off. From past experimentation with large'ish
p
gt; Hi Simon,
>
> On Monday, April 15, 2019 at 1:02:49 AM UTC+2, charettes wrote:
>>
>> and there's no way to turn off only this form of string normalization,
>> it's all or nothing.
>>
>
> So the black --help output lists:
> -S, --skip-string-normal
As I've said on the ticket I think we should make this change as
it's backward compatible and more coherent with the other
RelatedObjectDoesNotExist usages of the related fields API.
Cheers,
Simon
Le mardi 16 avril 2019 07:22:52 UTC-4, David Beitey a écrit :
>
> This continues the discussion from
I feel like it would be worse as it would break formatting changes across
multiple commits,
creating an inconsistent formatting code base and generating large
unrelated changes diff
when altering a still untouched file which would make the review harder.
Cheers,
Simon
Le mardi 16 avril 2019 10:
Hello Raphael,
> Have there ever been any surveys about how the size of Django projects? I
don't know the value of investigating this further except for our own usage.
I'm not aware of any similar surveys in the recent years but I would say *240
models across 90 apps, with roughly 500 migration
ge of
select_related and prefetch_related.
One thing to note is that the package is still opt-in in the sense that it
requires sealing querysets
but we're thinking of adding a setting that enables it by default for all
models.
Cheers,
Simon
[0] https://github.com/charettes/django-seal
Hello Haki,
This should probably have been posted to the django-users list given this
one
is for the development of Django itself but since there has been some
recent and ungoing
development in this area I'll reply here.
First there has been work to reuse annotation aliases that is in the maste
Hello Alexandr,
I agree with Anssi and you that adding a method to perform a subquery
pushdown would be useful.
FWIW #24462 and #28333 are not the only tickets where that was proposed as
a solution.
Searching for "subquery" and "pushdown" should bring a few other tickets.
There are also intern
Hello Christian,
I don't have an exact answer for you but there's open tickets about making
management
commands use logging instead of custom output wrappers that might interest
you.
Simon
[0] https://code.djangoproject.com/ticket/21429
[1] https://code.djangoproject.com/ticket/27877
Le samed
I agree with what James eloquently said, the issue is more complicated it
appears.
Simon
Le mardi 15 octobre 2019 05:59:27 UTC-4, James Bennett a écrit :
>
> This request is a bit more complicated than I think people
> realize. There's no practical way I can see to have the __repr__() of
> a Que
During the refactor of lazy operations[1] abstract models stopped resolving
their related field model reference by themselves[2][3] in order to prevent
pending lookup pollution. This was necessary in order to warn the users
about
unresolved relationships in a reliable way.
This change introduced
Shai, I think I have a viable solution for the the second kind of data
migration your are mentioning.
https://code.djangoproject.com/ticket/26064#ticket
Simon
Le samedi 9 janvier 2016 11:30:01 UTC-5, Shai Berger a écrit :
>
> On Saturday 09 January 2016 04:56:11 'Hugo Osvaldo Barrera' via Django
Thanks for your input everyone.
You convinced me we should with the third option[1] for now.
Markus, nothing prevent us from changing this behavior in the future
if there's a need for it but since this is a regression and we don't have
a clear backward compatible upgrade path defined we should go
Hi Elton,
>From a quick look this branch seems to handle attributes inherited from
possible `Meta` bases.
e.g.
class Foo(models.Model):
class Meta:
app_label = 'app'
class Bar(models.Model):
class Meta(Foo.Meta):
pass
assert 'app_label' not in Bar.Meta.__dict__
assert B
5, Elton Pereira de Lima a écrit :
>
> Hello charettes!
>
> Analyzing the code further, I saw that it was impossible for the Bar Meta
> class inherits from Foo.Meta because when this code
> <https://github.com/django/django/blob/master/django/db/models/base.py#L108>
> is execu
FWIW, as Marteen pointed out, the `Meta` attribute is only available on
abstract classes because of these lines
<https://github.com/django/django/blob/5c048f95cc4a988a35bfd94655469310830a2cf8/django/db/models/base.py#L274-L280>
.
Simon
Le lundi 18 janvier 2016 13:09:16 UTC-5, charettes a
Hi Patryk,
> Currently we have Prefetch objects that kind of solve this problem for M2M
> relations but perhaps it would be nice to also be able to use QuerySets in
> select_related() or even in filter(). I don't think Prefetch objects are
best
> suited for that and I personally find having to in
FWIW I've been working around this limitation by adding a suffix
to my `DATABASES['alias']['TEST']['NAME']` setting if the project
VCS branch is not the default one.
e.g. for Git
import subprocess
branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref',
'HEAD']).strip()
if branch
> That hasher, being the fastest non-plaintext hasher around, is quite
useful
> when running tests: it allows login checks to be performed much faster.
This argument came up a couple of time in the past and from what I remember
the Django test suite itself spends a significant amount of time has
> Tests that verify the password hasher will need to run the hash algorithm
> regardless.
I'm aware of that but this only represents a small fraction of the tests.
Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes > wr
> Tests that verify the password hasher will need to run the hash algorithm
> regardless.
I'm aware of that but this only represents a small fraction of the tests.
Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes > wr
26186#comment:8
[4] https://code.djangoproject.com/ticket/24215
Le vendredi 8 janvier 2016 16:16:33 UTC-5, charettes a écrit :
>
> During the refactor of lazy operations[1] abstract models stopped resolving
> their related field model reference by themselves[2][3] in order to prevent
&g
eally
convoluted before the lazy operations refactor.
Simon
Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit :
>
> On Tuesday 09 February 2016 23:33:50 charettes wrote:
> > Hi everyone,
> >
> > The chosen fix[1] unfortunately introduced a new regression[2]
101 - 200 of 232 matches
Mail list logo
