Proposal of standardize of reverse foreign key and m2m

[Albert]

Hi,

I am working on ticket https://code.djangoproject.com/ticket/19580
https://github.com/django/django/pull/15318

Currently (in the patch) unsaved object raises error when trying to use reverse 
foreign key or m2m relation. (Change in FK in patch)

Other issue that is worth to consider is when saved object has nullable 
referenced field.

class Manufacturer(models.Model):
name = models.CharField(max_length=100, null=True, blank=True, unique=True)

class Car(models.Model):
manufacturer = models.ForeignKey(Manufacturer, null=True, blank=True, 
to_field="name")

Car().save()
m = Manufacturer()
m.save()
m.car_set.all() # returns empty QuerySet 

but when we try call on this relation methods add/get_or_create/remove/clear it 
raises ValueError like M2M (Change in FK in patch)

Same case with M2M

class Pizza(models.Model):
name = models.CharField(max_length=100, null=True, blank=True)

class Topping(models.Model):
pizzas = models.ManyToMany(Pizza, through="PizzaTopping")

class PizzaTopping(models.Model):
pizza = models.ForeignKey(Pizza, null=True, blank=True, to_field="name")
topping = models.ForeignKey(Topping)
 
Topping().save()
p = Pizza()
p.save()
p.topping_set().all() # raise ValueError "" needs to 
have a value for field "name" before this many-to-many relation can be used.

Implementation of M2M seems to be correct because behavior is consistent - in 
every case when value of referenced field is None it raises error.
See comment in similar ticket (10 years old) 
https://code.djangoproject.com/ticket/17541#comment:8

I am in doubt if suggested in the ticket solution is correct (it is 9 years 
old) because in most cases it will raise error but only when there is an 
attempt to use query there is empty QuerySet returned.
Proposal is to raise error instead return empty QuerySet in Foreign Key like 
M2M does.

Albert

-- 
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/ngqfpcasjzabfoyaclqg%40xdkw.

Deprecation of using pk in public ORM API

[Albert]

Hi Daryl,I agree and disagree with you, it depends on place and context of 
using "pk" alias :)I am not sure if it is good in filter and as object 
attribute. For our internal use we could use "_pk" or other name.You motivated 
me to check one thing.class Car(models.Model):    pk = 
models.IntegerField(primary_key=True)(fields.E003) 'pk' is a reserved word that 
cannot be used as a field name.That is because we implicity create "pk" field 
(what is against The Zen of Python - Explicit is better than implicit ;)) and 
it is used in public api and internally.Basic idea, introduced at the beginning 
of Django (16 years ago), assumes that every table has primary key. What is not 
true in real life.If we released this, developers could create (if they like 
generic):class ModelA(models.Model):    pk = 
models.IntegerField(primary_key=True, db_column="id")class 
ModelB(models.Model):    pk = models.CharField(max_length=10, 
primary_key=True, db_column="name")class 
ModelC(models.Model):    pk = 
models.DateTimeField(primary_key=True, db_column="created_on")and can filter by 
"pk" or use as object attribute as they do now.This is more flexible from our 
point of view. This also allow create models without prlmary key. Models could 
have method or property "has_primary_key" that will return True or Falseor 
"get_primary_key" which could return None if PK doesn't exist otherwise 
dictionary {: }. I think that something 
like this is used internally. Of course it would involve changes in other parts 
of Django like generic views, admin panel etc. But step by step we could 
improve it.Until we allow users use "pk" alias, created implicity, in filters 
(public orm api) and as object attribute we have hands tied.

-- 
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/muwmdzznxleaadxvzhqk%40dccs.

Re: AWS RDS Proxy and session pinning

[dans...@gmail.com]

We already do that - our backend has some other work to do since we use AWS 
Secrets Manager to store database passwords, and also the hostname, so that 
our settings.DATABASES does not contain the PASSWORD but must contain a 
SECRET_ID.  The question is whether this is worth promoting since AWS RDS 
Proxy (and other similar proxy managers) are quite common.

On Monday, January 31, 2022 at 6:35:00 PM UTC-5 Adam Johnson wrote:

> Hi!
>
> Good to hear about the use of RDS Proxy. I have considered looking at it 
> to help scaling.
>
> You should be able to bypass the timezone check yourself with a little 
> subclassing. You can implement this yourself with a subclassed database 
> backend like so: 
> https://docs.djangoproject.com/en/4.0/ref/databases/#subclassing-the-built-in-database-backends
>  
> . Use it to replace the ensure_timezone() method with appropriate logic.
>
> That may be all that's required. It would be good to know if that works 
> before considering changing Django.
>
> Thanks,
>
> Adam
>
> On Mon, Jan 31, 2022 at 10:30 PM dans...@gmail.com  
> wrote:
>
>> Sorry - lest I miscommunicate - the DBAs make the default equivalent to 
>> EST5EDT, rather than UTC.   Django team leads (me and David), want USE_TZ = 
>> True to be on for all the applications, and because of this the postgresql 
>> backend will issue SET TIMEZONE UTC in 
>> django/db/backends/postgreql/base.py:209 (ensure_timezone).  At the same 
>> time, different applications and frameworks have different opinions and the 
>> DBAs try to satisfy us all, but can forget.  This issue of session pinning 
>> with connection pooling servers (such as RDS Proxy)  may be more general, 
>> and it may be good to not always set the timezone, but I want to discuss 
>> before filing an issue.
>>
>> On Monday, January 31, 2022 at 5:24:46 PM UTC-5 dans...@gmail.com wrote:
>>
>>> Hi Django developers,
>>>
>>> At the National Library of Medicine we are doing a lot of Django and 
>>> AWS.  For some of the applications with heavier traffic, we are using RDS 
>>> Proxy within AWS.  RDS Proxy is sort of like a managed version of pgbouncer 
>>> or pg-pool-II - it must be rather AWS customized because of the way it 
>>> manages authentication.
>>>
>>> Anyway, we found some problems for two reasons:
>>>
>>>- Our DBAs make the default timezone of the database UTF-8 is AWS 
>>>CloudFormation to create the databases.
>>>- When "ensure_timezone" runs and sets the timezone, that database 
>>>session is "pinned", so that it will not be shared.
>>>
>>> Since we already have our own PostgreSQL backend for a couple of other 
>>> reasons, I just wrote a version of ensure_timezone which fails loudly if 
>>> the timezone is not UTF-8 rather than set the timezone.  I probably should 
>>> have discussed the issue on this list, and I am remedying this.
>>>
>>> The failure to manage database connections with RDS Proxy is a pretty 
>>> severe error, and I am wondering what the community thinks about a 
>>> connection specific setting about how the timezone should be handled?   For 
>>> lower traffic applications, SET TIMEZONE is fine.  For higher traffic 
>>> applications, raising ImproperlyConfigured is better.   
>>>
>>> Does the group think that a Postgreql specific setting/option should be 
>>> implemented to prevent session pinning?
>>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ecc0c527-465a-45c7-b6ff-3c35c56824bfn%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/654dc44a-98d3-422a-aa45-fc719eae0da6n%40googlegroups.com.

Re: Proposal of standardize of reverse foreign key and m2m

[Asif Saif Uddin]

I get the following error while visiting the link 

Websites prove their identity via certificates, which are valid for a set 
time period. The certificate for code.djangoproject.com expired on 2/3/2022.
 
Error code: SEC_ERROR_EXPIRED_CERTIFICATE
 
On Thursday, February 3, 2022 at 2:17:33 AM UTC+6 al...@interia.eu wrote:

> Hi,
>
> I am working on ticket https://code.djangoproject.com/ticket/19580
> https://github.com/django/django/pull/15318
>
> Currently (in the patch) unsaved object raises error when trying to use 
> reverse foreign key or m2m relation. (Change in FK in patch)
>
> Other issue that is worth to consider is when saved object has nullable 
> referenced field.
>
> class Manufacturer(models.Model):
> name = models.CharField(max_length=100, null=True, blank=True, unique=True)
>
> class Car(models.Model):
> manufacturer = models.ForeignKey(Manufacturer, null=True, blank=True, 
> to_field="name")
>
> Car().save()
> m = Manufacturer()
> m.save()
> m.car_set.all() # returns empty QuerySet 
>
> but when we try call on this relation methods 
> add/get_or_create/remove/clear it raises ValueError like M2M (Change in FK 
> in patch)
>
> Same case with M2M
>
> class Pizza(models.Model):
> name = models.CharField(max_length=100, null=True, blank=True)
>
> class Topping(models.Model):
> pizzas = models.ManyToMany(Pizza, through="PizzaTopping")
>
> class PizzaTopping(models.Model):
> pizza = models.ForeignKey(Pizza, null=True, blank=True, to_field="name")
> topping = models.ForeignKey(Topping)
>
> Topping().save()
> p = Pizza()
> p.save()
> p.topping_set().all() # raise ValueError "" needs 
> to have a value for field "name" before this many-to-many relation can be 
> used.
>
> Implementation of M2M seems to be correct because behavior is consistent - 
> in every case when value of referenced field is None it raises error.
> See comment in similar ticket (10 years old) 
> https://code.djangoproject.com/ticket/17541#comment:8
>
> I am in doubt if suggested in the ticket solution is correct (it is 9 
> years old) because in most cases it will raise error but only when there is 
> an attempt to use query there is empty QuerySet returned.
> Proposal is to raise error instead return empty QuerySet in Foreign Key 
> like M2M does.
>
> Albert
>

-- 
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/db44ce9e-6765-469d-a359-7981d7558ec9n%40googlegroups.com.