Fellow Reports - April 2020
Week ending April 5, 2020. *Triaged:* https://code.djangoproject.com/ticket/31407 - RuntimeWarning when running AsyncHandlerRequestTests.test_unawaited_response. (accepted) https://code.djangoproject.com/ticket/31406 - Access date/time of request. (wontfix) https://code.djangoproject.com/ticket/31409 - Add warning regarding CheckConstraint and MySQL in docs. (wontfix) https://code.djangoproject.com/ticket/29170 - Unable to add triggers in migrations on Oracle. (accepted) https://code.djangoproject.com/ticket/31410 - Add check for fields of UniqueConstraints. (accepted) https://code.djangoproject.com/ticket/31411 - Use RENAME COLUMN on MariaDB 10.5.2+. (created) https://code.djangoproject.com/ticket/31413 - migrations.test_loader not isolated on databases that don't support transactions. (accepted) https://code.djangoproject.com/ticket/31414 - Django TestCase reads from "production" database with MySQL backend. (worksforme) https://code.djangoproject.com/ticket/31420 - Using SimpleLazyObject with a nested subquery annotation fails. (accepted) https://code.djangoproject.com/ticket/31421 - Running test suites hang on mac OX Catalina 10.15.2. (duplicate) https://code.djangoproject.com/ticket/31422 - Django response too long even do nothing. (invalid) https://code.djangoproject.com/ticket/31415 - QuerySet crashes when nested OuterRef is combined with an operator or used in function. (accepted) https://code.djangoproject.com/ticket/31416 - FieldError when migrating field to new model subclass. (accepted) https://code.djangoproject.com/ticket/31417 - Broken source links in docs. (invalid) https://code.djangoproject.com/ticket/31423 - Clarify using nested database transactions in atomic() docs. (accepted) *Reviewed/committed:* https://github.com/django/django/pull/12628 - Fixed #31403 -- Added support for returning fields from INSERT statements on MariaDB 10.5+. https://github.com/django/django/pull/12637 - Fixed #30864 -- Doc'd classproperty decorator. https://github.com/django/django/pull/12627 - Fixed #31375 -- Made contrib.auth.hashers.make_password() accept only bytes or strings. https://github.com/django/django/pull/12511 - Refs #31320 -- Warned against using BEGIN/COMMIT in RunSQL. https://github.com/django/django/pull/12596 - Fixed #31380 -- Added deployment system check for DJANGO_ALLOW_ASYNC_UNSAFE environment variable. https://github.com/django/django/pull/12649 - Used RENAME COLUMN on MariaDB 10.5.2+. https://github.com/django/django/pull/12652 - Refs #31051 -- Fixed reloading the database with circular related objects and natural keys for tests. https://github.com/django/django/pull/12634 - Fixed #31275 -- Optimized sql_flush() without resetting sequence on MySQL. https://github.com/django/django/pull/12654 - Fixed #31415 -- Fixed crash when nested OuterRef is used with operators or in database functions. *Reviewed:* https://github.com/django/django/pull/8477 - Fixed #28184 -- Allowed passing a callable storage to FileField. *Authored:* https://github.com/django/django/pull/12647 - Refs #12990 -- Moved PostgresSimpleLookup to the django.db.models.lookups.PostgresOperatorLookup. Best regards, Mariusz -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c501dbc5-8e65-4109-9bb9-8354621e54b2%40googlegroups.com.
Re: Problema validacion pbkdf2_sha256 hash
Hello Beltran,
If you want to convert hash to plain text
use PBKDF2HMAC function,
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
On Mon, Apr 6, 2020 at 4:14 AM Rogers Andres Diaz Beltran <
ing.rockerd...@gmail.com> wrote:
> Buenas tardes, esta es la documentacion del metodo:
>
> def check_password(self, raw_password):
> """
> Return a boolean of whether the raw_password was correct. Handles
> hashing formats behind the scenes.
> """
> def setter(raw_password):
> self.set_password(raw_password)
> # Password hash upgrades shouldn't be considered password changes.
> self._password = None
> self.save(update_fields=["password"])
> return check_password(raw_password, self.password, setter)
>
> Basicamente te regresa un bool que te indica si los passwords son iguales
> o no.
>
> Saludos!!
>
> El dom., 5 abr. 2020 a las 18:03, Mentor Carranza Carranza (<
> mentorcarran...@gmail.com>) escribió:
>
>> Gracias Rogers por tu pronta respuesta...revisare el tema de
>> Check_password ya que la opcion de comparar entre hash parecería que no
>> aplica ya que el hash nuevo generado es seguro que va a ser uno diferente
>> al ya almacenado aun siendo la misma clave. La pregunta concreta sería que
>> funcion utiliza djangointernamente para comparar claves...esa es la que yo
>> necesitaria...
>> Saludos y nuevamente gracias...voy a revisar.si alguien tiene un
>> ejemplo concreto le agradeceria.
>>
>> El domingo, 5 de abril de 2020, 16:02:27 (UTC-5), Rogers Andres Diaz
>> Beltran escribió:
>>>
>>> Buena la tardes, entiendo, debes tener en cuenta que el hash
>>> generado por django es una sola vía, es decir, desde el hash no podrás
>>> recuperar el texto plano de la contraseña. Lo que podes hacer es generar el
>>> nuevo password y verificarlo contra el password almacenado en la tabla
>>> users, si ambos hashes son idénticos podés estar seguro que ambos textos
>>> planos también lo son.
>>>
>>> Saludos!
>>>
>>> El dom., 5 de abril de 2020 1:21 p. m., Mentor Carranza Carranza <
>>> mentorc...@gmail.com> escribió:
>>>
Buen dia con todos,
Tengo un problema, y no se como resolverlo.
1.- Actualmente estoy utilizando la funcion MAKE_PASSWORD para generar
claves ingresadas por el usuario
2.- El formato que genera es algo como esto: hash >
pbkdf2_sha256$18$WrkfqaywlilB$BayvAJ9Rb4drbhIdX5uryVKl12wSEjzaXUeIMWbqIf4=
3.- Las clases de DJANGO que autentican el usuario, leen y validan
perfectamente estas claves que yo estoy generando con mis propios programas
y pantallas, si utilizo un metodo diferente la autenticacion que hace
DJANGO no detecta el formato por lo tanto no valida y no se puede ingresar.
4.- Si creo un superusuario a traves de: Python manage.py
createsuperuser se genera una clave con el mismo formato que el de
MAKE_PASSWORD
5.- Tengo una pantalla (interface) propia en donde permito que el
usuario cambie su contraseña ...en esta pantalla valido con javascript
cosas basicas de ingreso de datos y en un programa tipo PY valido que esta
clave NO SEA IGUAL a la que esta almacenada en la BASE DE DATOS, para ello
intento utilizar la funcion :
* pbkdf2_sha256.verify("Clave_ingresada_usuario", hash)*
*ValueError: not a valid pbkdf2_sha256 hash*
5.- Que metodo debo utilizar para validar la clave ingresada y
compararla con la almacenada en la base de datos?
Agradezco mucho a las personas y colegas que me guien en como resolver
este pequeño problema. Gracias
[image: Validacionclaves.png]
Mentor Carranza
Quito-Ecuador
--
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-d...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ff3c363d-0a29-41f2-90ac-0ebfbe797efe%40googlegroups.com
.
>>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3738e5df-a725-49a2-8adf-79bcd4127541%40googlegroups.com
>>
Subquery join support
Hello folks,
Following the discussion
https://groups.google.com/forum/#!topic/django-developers/b370mxfKCHg, I
would like to suggest adding the ability to join QuerySet with a subquery
clause to Django.
The benefits are pretty much described and discussed in the linked topic,
the only one I would like to add (my use case) is the ability to select
multiple columns from a Subquery without the need to repeat the subquery
clause, which hurts performance.
As Anssi Kääriäinen mentioned, generic subquery supports seems to be a
better idea than CTEs, and simple implementation as a starting point will
allow moving gradually and add RETURNING support later on (for nested
creates and updates).
I have created a working prototype and successfully using it in one of my
projects in production. After reading Daniel Miller's
https://github.com/dimagi/django-cte, I've rewritten the API inspired by
his ideas, plus tried to keep it as Django-style as possible.
Here is the usage example.
taxes = JoinedSubquery(Tax.objects.all())
products = Product.objects.all()
# .join is probably better be placed in QuerySet class, so it will be
products.join(taxes, ...)
products_with_taxes = taxes.join(
products,
join_type=LOUTER, # Optional argument, LOUTER by default
country=taxes.F('product_country'), # Also Q objects are supported
type=taxes.F('product_type')
).annotate(
tax_amount=taxes.F('amount') # .join() and .annotate() calls needn't
to be chained
)
I am not sure about named joins discussed in the CTE topic
qs.attach(q1=some_qs).filter(a=F('q1__b'))
It seems to be more implicit and harder to implement, requiring changes to
existing functionality and thus introducing a big patch which I would like
to avoid.
It is not possible to follow relations in *join.F* expressions, but it is
easily achievable by firstly fetching needed columns by *annotate*(), so I
don't see the need to implement it.
Source code is available here
https://gist.github.com/tatarinov1997/126c49c4b1bb44ae6c57afbc5f43f58d ,
tested with Django 2.2. Feel free to copy and play around.
So, please let me know what do you think about it. I am willing to continue
working on it, and any help is appreciated.
Thanks,
Alexandr.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8c41e40f-876c-46c0-9e24-09e8c72592ce%40googlegroups.com.
Adding ability to choose AutoField type (signed vs unsigned)
Hi folks, I’ve been working on ticket #56 "Primary key columns should be UNSIGNED" (really old) for a while now. It’s cumbersome and hard to fix for some reasons, including backwards compatibility, nothing that a single PR can solve but I’ll try to summarize where things are at this moment. Hopefully we can get to a consensus so I can continue. The problem: Django has been storing primary keys as signed integers since the beginning and this is considered a waste of resources. Very few people seem to use negative values as primary keys, apparently. The desired solution: We want to change that in a backwards-compatible way to not cause migrations to happen in all projects using Django, in all of a sudden. This is where things start to get difficult. These are the links for the related ticket and PR up to this point: https://code.djangoproject.com/ticket/56 (Primary key columns should be UNSIGNED) https://github.com/django/django/pull/11900 (PR) — While I was working on PR 11900, I stumbled across this other PR 8924 "BigAutoField as new default in 2.0”, and a particular comment from Nick Pope got my attention: https://github.com/django/django/pull/8924#issuecomment-516792989 The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of sense to me, as we would be able to keep things backwards compatible. My first reaction after following that discussion, was to add a missing part that would likely help, which was the PositiveBigIntegerField. This is already fixed and merged: https://code.djangoproject.com/ticket/30987 — Now that we have PositiveBigIntegerField merged in, we can also have PositiveBigAutoField and finally move forward with ticket #56. But we’d still need the ability to set a different default Auto Field. To achieve this, I’ve created a new ticket and Mariusz Felisiak suggested to bring this discussion to the developers list, whether or not we should move forward with this approach: https://code.djangoproject.com/ticket/31007 I want to hear from you folks, whether or not we can get to a consensus on adding this new setting but also, hear any concerns or issues you can anticipate. Ideally, this new setting would default to AutoField until Django 4? After that we can make it default to PositiveBigAutoField. We could (or should) also change the project template to set DEFAULT_AUTOFIELD to PositiveBigAutoField for new projecst, as suggested in Nick Pope's comment above. Thank you -- Caio -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8E947B86-2228-4DD3-9D6A-C1B6D757652E%40gmail.com.
RE: Subquery join support
It is my opinion that the Subquery object that already exists in Django should
act as a CTE.
There is a ticket for this feature already:
https://code.djangoproject.com/ticket/28919
I have noticed that several developers have proposed several different patches
for CTEs, but I do not know why they have never made it in. Perhaps someone
with more knowledge on that matter can help.
From: django-developers@googlegroups.com
On Behalf Of Alexandr Tatarinov
Sent: Monday, April 6, 2020 3:22 AM
To: Django developers (Contributions to Django itself)
Subject: Subquery join support
Hello folks,
Following the discussion
https://groups.google.com/forum/#!topic/django-developers/b370mxfKCHg, I would
like to suggest adding the ability to join QuerySet with a subquery clause to
Django.
The benefits are pretty much described and discussed in the linked topic, the
only one I would like to add (my use case) is the ability to select multiple
columns from a Subquery without the need to repeat the subquery clause, which
hurts performance.
As Anssi Kääriäinen mentioned, generic subquery supports seems to be a better
idea than CTEs, and simple implementation as a starting point will allow moving
gradually and add RETURNING support later on (for nested creates and updates).
I have created a working prototype and successfully using it in one of my
projects in production. After reading Daniel Miller's
https://github.com/dimagi/django-cte, I've rewritten the API inspired by his
ideas, plus tried to keep it as Django-style as possible.
Here is the usage example.
taxes = JoinedSubquery(Tax.objects.all())
products = Product.objects.all()
# .join is probably better be placed in QuerySet class, so it will be
products.join(taxes, ...)
products_with_taxes = taxes.join(
products,
join_type=LOUTER, # Optional argument, LOUTER by default
country=taxes.F('product_country'), # Also Q objects are supported
type=taxes.F('product_type')
).annotate(
tax_amount=taxes.F('amount') # .join() and .annotate() calls needn't to be
chained
)
I am not sure about named joins discussed in the CTE topic
qs.attach(q1=some_qs).filter(a=F('q1__b'))
It seems to be more implicit and harder to implement, requiring changes to
existing functionality and thus introducing a big patch which I would like to
avoid.
It is not possible to follow relations in join.F expressions, but it is easily
achievable by firstly fetching needed columns by annotate(), so I don't see the
need to implement it.
Source code is available here
https://gist.github.com/tatarinov1997/126c49c4b1bb44ae6c57afbc5f43f58d , tested
with Django 2.2. Feel free to copy and play around.
So, please let me know what do you think about it. I am willing to continue
working on it, and any help is appreciated.
Thanks,
Alexandr.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8c41e40f-876c-46c0-9e24-09e8c72592ce%40googlegroups.com.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1a5ac0adfa6a4b2a98b1a7862a6a2246%40iss2.ISS.LOCAL.
Re: Adding ability to choose AutoField type (signed vs unsigned)
I'm in favour of the move. The setting strategy seems appropriate.
Simon's comment on the PR that this affects a small % of projects is true.
But if your project does reach that scale, you're probably one of the
bigger Django organizations in the world - hopefully key advocates for the
framework. It's also possible to hit this on smaller projects with tables
that import a lot of new rows, such as rolling time series data imports.
Also, this problem is *highly* asymmetric. Unnecessarily using big PK
fields wastes a little storage space - unlikely to be noticed. Migrating to
big PK fields can be a massive task (and can feel like "Django let you down
here with bad defaults") ("Ruby on Rails does it right!").
It will need a careful migration guide though. Pre-existing projects may
need to migrate one table at a time to reduce downtime/load, or keep the
setting to the smaller auto field forever. I'm happy to help with this.
One thing we *could* add is a deploy time system check (or a management
command, or something), to check what % of your tables' autofields' PK
values have been "used up." This allows larger projects to prioritize their
migrations.
On Mon, 6 Apr 2020 at 15:37, Caio Ariede wrote:
> Hi folks,
>
> I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"
> (really old) for a while now. It’s cumbersome and hard to fix for some
> reasons, including backwards compatibility, nothing that a single PR can
> solve but I’ll try to summarize where things are at this moment. Hopefully
> we can get to a consensus so I can continue.
>
> The problem: Django has been storing primary keys as signed integers since
> the beginning and this is considered a waste of resources. Very few people
> seem to use negative values as primary keys, apparently.
>
> The desired solution: We want to change that in a backwards-compatible way
> to not cause migrations to happen in all projects using Django, in all of a
> sudden. This is where things start to get difficult.
>
> These are the links for the related ticket and PR up to this point:
>
> https://code.djangoproject.com/ticket/56 (Primary key columns should be
> UNSIGNED)
> https://github.com/django/django/pull/11900 (PR)
>
> —
>
> While I was working on PR 11900, I stumbled across this other PR 8924
> "BigAutoField as new default in 2.0”, and a particular comment from Nick
> Pope got my attention:
>
> https://github.com/django/django/pull/8924#issuecomment-516792989
>
> The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of sense to
> me, as we would be able to keep things backwards compatible.
>
> My first reaction after following that discussion, was to add a missing
> part that would likely help, which was the PositiveBigIntegerField. This is
> already fixed and merged:
>
> https://code.djangoproject.com/ticket/30987
>
> —
>
> Now that we have PositiveBigIntegerField merged in, we can also have
> PositiveBigAutoField
> and finally move forward with ticket #56. But we’d still need the ability
> to set a different default Auto Field.
>
> To achieve this, I’ve created a new ticket and Mariusz Felisiak suggested
> to bring this discussion to the developers list, whether or not we should
> move forward with this approach:
>
> https://code.djangoproject.com/ticket/31007
>
> I want to hear from you folks, whether or not we can get to a consensus on
> adding this new setting but also, hear any concerns or issues you can
> anticipate.
>
> Ideally, this new setting would default to AutoField until Django 4? After
> that we can make it default to PositiveBigAutoField.
>
> We could (or should) also change the project template to set DEFAULT_AUTOFIELD
> to PositiveBigAutoField for new projecst, as suggested in Nick Pope's
> comment above.
>
>
> Thank you
>
> --
> Caio
>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8E947B86-2228-4DD3-9D6A-C1B6D757652E%40gmail.com
>
> .
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM0VqXrPbre-6YXSSnu2PBStQoijjoEH_9Wc-aB0gDEHBw%40mail.gmail.com.
Re: Adding ability to choose AutoField type (signed vs unsigned)
Sorry if I understand stuff incorrectly, but:
I agree with Adam where he discusses migration issues, but I also don't
see how "DEFAULT_AUTOFIELD" setting could leave tables out of the
migration(s).
My understanding is that it would cause immediate re-provisioning of all
the pk fields, including in the core django modules and third-party
modules. Some of them might have programmed their logic such as to
include some integer math around the primary keys (and now all auto
primary keys might be GUID).
If I understand the above correctly, the setting would have to be
per-module. Could it simply be done like this:
class PKMixin(object): id= models.UUIDField(primary_key=True, )
Naturally, then all desired models would (also) derive from this mixin.
A bit of a chore, but it would not require reconfiguration of all
migrations, just the ones the programmer would specify - and would only
be limited to their own module.
OTOH, JUST FOR the unsigned vs signed integer PK, it should be
relatively easy to modify makemigrations code detect existing migrations
for the model, detect that the only difference is IntegerField vs
PositiveIntegerField and in this case skip generating the migration (for
migrating the field to an unsigned one). There could also be a flag to
the management command specifying to force generating said migrations.
Of course, ignore if this is gibberish.
LP,
Jure
On 06/04/2020 17:11, Adam Johnson wrote:
I'm in favour of the move. The setting strategy seems appropriate.
Simon's comment on the PR that this affects a small % of projects is
true. But if your project does reach that scale, you're probably one
of the bigger Django organizations in the world - hopefully key
advocates for the framework. It's also possible to hit this on smaller
projects with tables that import a lot of new rows, such as rolling
time series data imports.
Also, this problem is *highly* asymmetric. Unnecessarily using big PK
fields wastes a little storage space - unlikely to be noticed.
Migrating to big PK fields can be a massive task (and can feel like
"Django let you down here with bad defaults") ("Ruby on Rails does it
right!").
It will need a careful migration guide though. Pre-existing projects
may need to migrate one table at a time to reduce downtime/load, or
keep the setting to the smaller auto field forever. I'm happy to help
with this.
One thing we *could* add is a deploy time system check (or a
management command, or something), to check what % of your tables'
autofields' PK values have been "used up." This allows larger projects
to prioritize their migrations.
On Mon, 6 Apr 2020 at 15:37, Caio Ariede > wrote:
Hi folks,
I’ve been working on ticket #56 "Primary key columns should be
UNSIGNED" (really old) for a while now. It’s cumbersome and hard
to fix for some reasons, including backwards compatibility,
nothing that a single PR can solve but I’ll try to summarize where
things are at this moment. Hopefully we can get to a consensus so
I can continue.
The problem: Django has been storing primary keys as signed
integers since the beginning and this is considered a waste of
resources. Very few people seem to use negative values as primary
keys, apparently.
The desired solution: We want to change that in a
backwards-compatible way to not cause migrations to happen in all
projects using Django, in all of a sudden. This is where things
start to get difficult.
These are the links for the related ticket and PR up to this point:
https://code.djangoproject.com/ticket/56 (Primary key columns
should be UNSIGNED)
https://github.com/django/django/pull/11900 (PR)
—
While I was working on PR 11900, I stumbled across this other PR
8924 "BigAutoField as new default in 2.0”, and a particular
comment from Nick Pope got my attention:
https://github.com/django/django/pull/8924#issuecomment-516792989
The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of
sense to me, as we would be able to keep things backwards compatible.
My first reaction after following that discussion, was to add a
missing part that would likely help, which was
the PositiveBigIntegerField. This is already fixed and merged:
https://code.djangoproject.com/ticket/30987
—
Now that we have PositiveBigIntegerField merged in, we can also
have PositiveBigAutoField and finally move forward with ticket
#56. But we’d still need the ability to set a different default
Auto Field.
To achieve this, I’ve created a new ticket and Mariusz Felisiak
suggested to bring this discussion to the developers list, whether
or not we should move forward with this approach:
https://code.djangoproject.com/ticket/31007
I want to hear from you folks, whether or not we can get to a
consensus on adding this new setting but also, h
Re: Adding ability to choose AutoField type (signed vs unsigned)
Jure - yes switching the setting should generate migrations for all
affected models. The migration guide would cover changing models' primary
key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as
you've suggested. Maybe Django should provide such a mixin to ease the
migration.
primary keys might be GUID
>
The proposal is not to move to GUID's/UUID's, as you've used in your
example. It's to move to bigger integers.
UUID's are a bad idea for database performance, as they distribute randomly
across the table, preventing any cache wins. On autoincrement tables, the
tail end of each table is normally most frequently read and written and
thus cached in memory. I don't think Django should ever suggest UUID's as
primary keys.
On Mon, 6 Apr 2020 at 16:46, Jure Erznožnik
wrote:
> Sorry if I understand stuff incorrectly, but:
>
> I agree with Adam where he discusses migration issues, but I also don't
> see how "DEFAULT_AUTOFIELD" setting could leave tables out of the
> migration(s).
>
> My understanding is that it would cause immediate re-provisioning of all
> the pk fields, including in the core django modules and third-party
> modules. Some of them might have programmed their logic such as to include
> some integer math around the primary keys (and now all auto primary keys
> might be GUID).
>
> If I understand the above correctly, the setting would have to be
> per-module. Could it simply be done like this:
>
> class PKMixin(object):id = models.UUIDField(primary_key=True, )
>
> Naturally, then all desired models would (also) derive from this mixin. A
> bit of a chore, but it would not require reconfiguration of all migrations,
> just the ones the programmer would specify - and would only be limited to
> their own module.
>
> OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively
> easy to modify makemigrations code detect existing migrations for the
> model, detect that the only difference is IntegerField vs
> PositiveIntegerField and in this case skip generating the migration (for
> migrating the field to an unsigned one). There could also be a flag to the
> management command specifying to force generating said migrations.
>
> Of course, ignore if this is gibberish.
>
> LP,
> Jure
>
>
> On 06/04/2020 17:11, Adam Johnson wrote:
>
> I'm in favour of the move. The setting strategy seems appropriate.
>
> Simon's comment on the PR that this affects a small % of projects is true.
> But if your project does reach that scale, you're probably one of the
> bigger Django organizations in the world - hopefully key advocates for the
> framework. It's also possible to hit this on smaller projects with tables
> that import a lot of new rows, such as rolling time series data imports.
>
> Also, this problem is *highly* asymmetric. Unnecessarily using big PK
> fields wastes a little storage space - unlikely to be noticed. Migrating to
> big PK fields can be a massive task (and can feel like "Django let you down
> here with bad defaults") ("Ruby on Rails does it right!").
>
> It will need a careful migration guide though. Pre-existing projects may
> need to migrate one table at a time to reduce downtime/load, or keep the
> setting to the smaller auto field forever. I'm happy to help with this.
>
> One thing we *could* add is a deploy time system check (or a management
> command, or something), to check what % of your tables' autofields' PK
> values have been "used up." This allows larger projects to prioritize their
> migrations.
>
> On Mon, 6 Apr 2020 at 15:37, Caio Ariede wrote:
>
>> Hi folks,
>>
>> I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"
>> (really old) for a while now. It’s cumbersome and hard to fix for some
>> reasons, including backwards compatibility, nothing that a single PR can
>> solve but I’ll try to summarize where things are at this moment. Hopefully
>> we can get to a consensus so I can continue.
>>
>> The problem: Django has been storing primary keys as signed integers
>> since the beginning and this is considered a waste of resources. Very few
>> people seem to use negative values as primary keys, apparently.
>>
>> The desired solution: We want to change that in a backwards-compatible
>> way to not cause migrations to happen in all projects using Django, in all
>> of a sudden. This is where things start to get difficult.
>>
>> These are the links for the related ticket and PR up to this point:
>>
>> https://code.djangoproject.com/ticket/56 (Primary key columns should be
>> UNSIGNED)
>> https://github.com/django/django/pull/11900 (PR)
>>
>> —
>>
>> While I was working on PR 11900, I stumbled across this other PR 8924
>> "BigAutoField as new default in 2.0”, and a particular comment from Nick
>> Pope got my attention:
>>
>> https://github.com/django/django/pull/8924#issuecomment-516792989
>>
>> The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of sense to
>> me, as we would be able to keep things backwards compatible.
Re: Problema validacion pbkdf2_sha256 hash
¡Hola! (Traducido con Google Translate, inglés al final)
Creo que has encontrado la lista de correo incorrecta para esta
publicación. Esta
lista de correo es para discutir el desarrollo de Django en sí, no para el
soporte con Django. Esto significa la discusión de errores y
características en Django, en lugar de en el código que lo usa. Es poco
probable que las personas en esta lista respondan a su consulta de soporte
con su tiempo y energía limitados.
Para obtener asistencia, siga la página "Obtención de ayuda":
https://docs.djangoproject.com/en/3.0/faq/help/
Gracias por su comprensión,
Adán
---
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.
For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/
Thanks for your understanding,
Adam
On Mon, 6 Apr 2020 at 13:29, Hasnat Jutt wrote:
> Hello Beltran,
>
>If you want to convert hash to plain text
> use PBKDF2HMAC function,
> from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
>
> On Mon, Apr 6, 2020 at 4:14 AM Rogers Andres Diaz Beltran <
> ing.rockerd...@gmail.com> wrote:
>
>> Buenas tardes, esta es la documentacion del metodo:
>>
>> def check_password(self, raw_password):
>> """
>> Return a boolean of whether the raw_password was correct. Handles
>> hashing formats behind the scenes.
>> """
>> def setter(raw_password):
>> self.set_password(raw_password)
>> # Password hash upgrades shouldn't be considered password changes.
>> self._password = None
>> self.save(update_fields=["password"])
>> return check_password(raw_password, self.password, setter)
>>
>> Basicamente te regresa un bool que te indica si los passwords son iguales
>> o no.
>>
>> Saludos!!
>>
>> El dom., 5 abr. 2020 a las 18:03, Mentor Carranza Carranza (<
>> mentorcarran...@gmail.com>) escribió:
>>
>>> Gracias Rogers por tu pronta respuesta...revisare el tema de
>>> Check_password ya que la opcion de comparar entre hash parecería que no
>>> aplica ya que el hash nuevo generado es seguro que va a ser uno diferente
>>> al ya almacenado aun siendo la misma clave. La pregunta concreta sería que
>>> funcion utiliza djangointernamente para comparar claves...esa es la que yo
>>> necesitaria...
>>> Saludos y nuevamente gracias...voy a revisar.si alguien tiene un
>>> ejemplo concreto le agradeceria.
>>>
>>> El domingo, 5 de abril de 2020, 16:02:27 (UTC-5), Rogers Andres Diaz
>>> Beltran escribió:
Buena la tardes, entiendo, debes tener en cuenta que el hash
generado por django es una sola vía, es decir, desde el hash no podrás
recuperar el texto plano de la contraseña. Lo que podes hacer es generar el
nuevo password y verificarlo contra el password almacenado en la tabla
users, si ambos hashes son idénticos podés estar seguro que ambos textos
planos también lo son.
Saludos!
El dom., 5 de abril de 2020 1:21 p. m., Mentor Carranza Carranza <
mentorc...@gmail.com> escribió:
> Buen dia con todos,
>
>
> Tengo un problema, y no se como resolverlo.
>
> 1.- Actualmente estoy utilizando la funcion MAKE_PASSWORD para generar
> claves ingresadas por el usuario
> 2.- El formato que genera es algo como esto: hash >
>
> pbkdf2_sha256$18$WrkfqaywlilB$BayvAJ9Rb4drbhIdX5uryVKl12wSEjzaXUeIMWbqIf4=
> 3.- Las clases de DJANGO que autentican el usuario, leen y validan
> perfectamente estas claves que yo estoy generando con mis propios
> programas
> y pantallas, si utilizo un metodo diferente la autenticacion que hace
> DJANGO no detecta el formato por lo tanto no valida y no se puede
> ingresar.
> 4.- Si creo un superusuario a traves de: Python manage.py
> createsuperuser se genera una clave con el mismo formato que el de
> MAKE_PASSWORD
> 5.- Tengo una pantalla (interface) propia en donde permito que el
> usuario cambie su contraseña ...en esta pantalla valido con javascript
> cosas basicas de ingreso de datos y en un programa tipo PY valido que esta
> clave NO SEA IGUAL a la que esta almacenada en la BASE DE DATOS, para
> ello
> intento utilizar la funcion :
>
>
>
> * pbkdf2_sha256.verify("Clave_ingresada_usuario", hash)*
>
>*ValueError: not a valid pbkdf2_sha256 hash*
>
> 5.- Que metodo debo utilizar para validar la clave ingresada y
> compararla con la almacenada en la base de datos?
>
> Agradezco mucho a las personas y colegas que me guien en como resolver
> este pequeño problema. Gracias
>
>
>
>
Re: [Probably BUG] set_password and check_password accept values other than string as parameters
On Thursday, March 12, 2020 at 6:16:31 PM UTC+1, Dawid Czeluśniak wrote: > > I think that the root question here is: should we allow users to create > passwords from anything that is not str? > I would reduce it to allow strings & bytes and am willing to review a patch and push it through. It is security sensitive enough that I think we can ignore the (imo non-existant) backwards compatibility issues. Cheers, Florian -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b667a3cd-6334-4496-a174-5b41351450a3%40googlegroups.com.
Re: [Probably BUG] set_password and check_password accept values other than string as parameters
For the record a PR doing exactly that has been reviewed and merged already and should be of 3.1 https://github.com/django/django/pull/12627 Cheers, Simon Le lundi 6 avril 2020 13:54:27 UTC-4, Florian Apolloner a écrit : > > > > On Thursday, March 12, 2020 at 6:16:31 PM UTC+1, Dawid Czeluśniak wrote: >> >> I think that the root question here is: should we allow users to create >> passwords from anything that is not str? >> > > I would reduce it to allow strings & bytes and am willing to review a > patch and push it through. It is security sensitive enough that I think we > can ignore the (imo non-existant) backwards compatibility issues. > > Cheers, > Florian > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b41c7663-7718-4ecf-9ebd-23ac39ad2678%40googlegroups.com.
Re: [Probably BUG] set_password and check_password accept values other than string as parameters
Hi Florian, We've already merged this change https://github.com/django/django/commit/8aa71f4e8706b6b3e4e60aaffb29d004e1378ae3.Please feel-free to review it and return any comments. Best, Mariusz -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e84b9971-5aa7-4c58-a0a3-d9f204bc0362%40googlegroups.com.
Re: Subquery join support
Accidentally removed gist, new one is here
https://gist.github.com/tatarinov1997/068fe786366401ed640dcbbbe5d959e4
On Monday, 6 April 2020 16:34:55 UTC+3, Alexandr Tatarinov wrote:
>
> Hello folks,
>
> Following the discussion
> https://groups.google.com/forum/#!topic/django-developers/b370mxfKCHg, I
> would like to suggest adding the ability to join QuerySet with a subquery
> clause to Django.
> The benefits are pretty much described and discussed in the linked topic,
> the only one I would like to add (my use case) is the ability to select
> multiple columns from a Subquery without the need to repeat the subquery
> clause, which hurts performance.
> As Anssi Kääriäinen mentioned, generic subquery supports seems to be a
> better idea than CTEs, and simple implementation as a starting point will
> allow moving gradually and add RETURNING support later on (for nested
> creates and updates).
>
> I have created a working prototype and successfully using it in one of my
> projects in production. After reading Daniel Miller's
> https://github.com/dimagi/django-cte, I've rewritten the API inspired by
> his ideas, plus tried to keep it as Django-style as possible.
> Here is the usage example.
>
> taxes = JoinedSubquery(Tax.objects.all())
> products = Product.objects.all()
>
> # .join is probably better be placed in QuerySet class, so it will be
> products.join(taxes, ...)
> products_with_taxes = taxes.join(
> products,
> join_type=LOUTER, # Optional argument, LOUTER by default
> country=taxes.F('product_country'), # Also Q objects are supported
> type=taxes.F('product_type')
> ).annotate(
> tax_amount=taxes.F('amount') # .join() and .annotate() calls needn't
> to be chained
> )
>
>
> I am not sure about named joins discussed in the CTE topic
> qs.attach(q1=some_qs).filter(a=F('q1__b'))
>
> It seems to be more implicit and harder to implement, requiring changes to
> existing functionality and thus introducing a big patch which I would like
> to avoid.
>
> It is not possible to follow relations in *join.F* expressions, but it is
> easily achievable by firstly fetching needed columns by *annotate*(), so
> I don't see the need to implement it.
>
> Source code is available here
> https://gist.github.com/tatarinov1997/126c49c4b1bb44ae6c57afbc5f43f58d ,
> tested with Django 2.2. Feel free to copy and play around.
>
> So, please let me know what do you think about it. I am willing to
> continue working on it, and any help is appreciated.
>
> Thanks,
> Alexandr.
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7935e9cd-d0f0-4680-be29-36aacce15004%40googlegroups.com.
Re: [Probably BUG] set_password and check_password accept values other than string as parameters
oh, I somehow missed that. thanks for the heads-up. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/497793c5-d4f8-4ab7-8e01-cbfd6822ca48%40googlegroups.com.
Re: Subquery join support
Great work on this, Alexandr. I've been thinking a lot about doing joins in Django to subqueries. As you point out, when you are doing several subquery annotations of the same subquery, just with different columns, that can really hurt performance. Currently, I've been recommending doing a JSON object as the subquery column. I really like the idea of an explicit join to a subquery, as it can perform significantly better - in the case where most of the rows share the same subquery, the database can perform the subquery once per distinct row joined, rather than once for each row. I think, instead of using a `JoinedSubquery`, we should just make it that a `Subquery`, containing unresolved OuterRef instances, can also be resolved by doing a `QuerySet.join(Subquery(...))`. We could also have a lateral argument that allowed a LATERAL JOIN to a subquery, but perhaps that's later down the track. (Actually, now I think about it, a QuerySet should probably just act as a Subquery when it's used as one, but perhaps that's too magic). Matt. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2bec9c0d-574c-493a-bbe2-fa58ab56%40googlegroups.com.
