Re: `Model.validate_unique` excluding partial unique constraint

[Gaga Ro]

> yeah didn't want to step on your toes but I got very excited about trying 
it out 

Don't worry about that, it's a good thing this motivated you enough to 
advance on this topic.

> I have a slight preference for the second option as it seems like it 
could be used in other context than constraints[0] but I'm curious about 
your thoughts?

Yes I agree that this should be independent from models. There is no reason 
to tie it to them, and if we want to do it anyway, it would be trivial to 
do using the new method. Or maybe we could have both we different named 
parameters and change the behaviour deping on those.

> Looking at [0] in more details I also feel like matches() could be a 
better name than check().

It should be obvious that the method return a boolean, matches sounds like 
that it could returns a list of the matches to me.

-- 
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/5160faab-5c8f-42a5-b7d6-6594770cee65n%40googlegroups.com.

Re: `Model.validate_unique` excluding partial unique constraint

[charettes]

> It looks like you went even further than that :D.

yeah didn't want to step on your toes but I got very excited about trying 
it out 

> Should we still add Q.check() (which will be as you said before), then 
refactor BaseConstraint.validate() to use it?

I think it would still be worth doing to avoid the Query(None), add_annotation, 
except FieldError, get_compiler() boilerplate but me might need to change 
the planed function signature.

What do you think of

def check(self, instance, exclude=None, using=DEFAULT_DB_ALIAS):
query = Query(None) 
for field in instance._meta.local_concrete_fields: 
if exclude and field.name in exclude: 
continue
value = getattr(instance, field.attname) 
query.add_annotation(Value(value, field), field.name, select=False) 
try: 
query.add_annotation(ExpressionWrapper(self, BooleanField()), 
'_check') 
 except FieldError: 
 # Check is referencing an excluded field 
 return None
 compiler = query.get_compiler(using=using) 
 return bool(compiler.execute_sql(SINGLE)[0])

Looks like it would deal with most of the boilerplate while still being 
flexible enough for our use case. Maybe we don't want to push down the 
model/exclude field notion this far though and require literals to be 
passed directly instead.

def check(self, against, using=DEFAULT_DB_ALIAS):
query = Query(None) 
for name, value in against.items():
if not hasattr('resolve_expression'):
value = Value(value)
query.add_annotation(value, name, select=False)
try: 
query.add_annotation(ExpressionWrapper(self, BooleanField()), 
'_check') 
 except FieldError: 
 # Check is referencing a missing field
 return None
 compiler = query.get_compiler(using=using) 
 return bool(compiler.execute_sql(SINGLE)[0])

I have a slight preference for the second option as it seems like it could 
be used in other context than constraints[0] but I'm curious about your 
thoughts? Looking at [0] in more details I also feel like matches() could 
be a better name than check().

Simon

[0] https://github.com/django/django/pull/388#issuecomment-8863209
Le mercredi 16 juin 2021 à 04:44:08 UTC-4, gaga...@gmail.com a écrit :

> It looks like you went even further than that :D.
>
> 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 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 
>>> you towards a deep rabbit hole and it seems pretty straightforward!
>>>
>>>
>>> https://github.com/django/django/compare/main...charettes:query-empty-model
>>>
>>> Le lundi 14 juin 2021 à 03:09:35 UTC-4, gaga...@gmail.com a écrit :
>>>
 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.
>
> First things first Lookup must be made a subclass of Expression which 
> is being worked on[0].
>
> Ideally Q would also be made a subclass of Expression but that's 
> likely a big can of worms so I'd focus on implementing it for Q only at 
> first.
>
> Now for the compiler part. Things are bit tricky here as these 
> expressions are not going to be bound to a model/table and most of the 
> sql.Query and resolve_expression machinery revolves around the 
> availability 
> of a Query.model: models.Model property. I think there's two solutions 
> here:
>
> 1. Adapt sql.Query so it can be *unbounded* meaning that it's .model 
> property type would change from models.Model to Optional[models.Model]. 
> 2. Follow the sql.RawQuery route and define a new sql.UnboundQuery 
> class that *looks* like a Query but doesn't allow any form of column 
> references or JOINs or filters (WHERE).
>
> In both cases the Query like object should prevent any form of column 
> references and JOINs with a comprehensible error messages (e.g. in 
> resolve_ref 
> and setup_join if go with 1.). I have a feeling 2. is easier to 
> implement but 1. seems like it could be a much more rewarding experience 
> for you and the community as you'll have to special case a couple of long 
> lived assumptions in django.db.models.sql.
>
> Depending on whether you choose the 1. or 2. you'll have to implement 
> a way for database backends to specify how to *wrap* the provided 
> expression in a SELECT statement. Most databases won't require any 
> special 

Re: Removal of USE_L10N setting

[Jacob Rief]

I in favor with René Fleschenberg's proposal to enforce localization using 
a template filter.
It happened too often, that someone forgot to unlocalize a primary key in 
their templates
causing unwanted results.

-- 
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/88ec616c-0dfa-4858-b282-dcfe923572d3n%40googlegroups.com.

Re: Removal of USE_L10N setting

[René Fleschenberg]

Hi Claude,

> I understand this concern. I wonder if that could be solved separately,
> for example by:
>  - returning int subclasses from AutoField's to_python (a bit like
> str/SafeString for handling escaping)
>  - not localizing those integers, unless use_l10n is forced (True)
> Does this look like a plan (even without touching USE_L10N)?


Sounds good to me!

-- 
René

-- 
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/4a346495-ded1-5eea-6265-ab5c0378fde9%40fleschenberg.net.

Re: `Model.validate_unique` excluding partial unique constraint

[Gaga Ro]

It looks like you went even further than that :D.

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 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 
>> you towards a deep rabbit hole and it seems pretty straightforward!
>>
>>
>> https://github.com/django/django/compare/main...charettes:query-empty-model
>>
>> Le lundi 14 juin 2021 à 03:09:35 UTC-4, gaga...@gmail.com a écrit :
>>
>>> 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.

 First things first Lookup must be made a subclass of Expression which 
 is being worked on[0].

 Ideally Q would also be made a subclass of Expression but that's likely 
 a big can of worms so I'd focus on implementing it for Q only at first.

 Now for the compiler part. Things are bit tricky here as these 
 expressions are not going to be bound to a model/table and most of the 
 sql.Query and resolve_expression machinery revolves around the 
 availability 
 of a Query.model: models.Model property. I think there's two solutions 
 here:

 1. Adapt sql.Query so it can be *unbounded* meaning that it's .model 
 property type would change from models.Model to Optional[models.Model]. 
 2. Follow the sql.RawQuery route and define a new sql.UnboundQuery 
 class that *looks* like a Query but doesn't allow any form of column 
 references or JOINs or filters (WHERE).

 In both cases the Query like object should prevent any form of column 
 references and JOINs with a comprehensible error messages (e.g. in 
 resolve_ref 
 and setup_join if go with 1.). I have a feeling 2. is easier to 
 implement but 1. seems like it could be a much more rewarding experience 
 for you and the community as you'll have to special case a couple of long 
 lived assumptions in django.db.models.sql.

 Depending on whether you choose the 1. or 2. you'll have to implement a 
 way for database backends to specify how to *wrap* the provided expression 
 in a SELECT statement. Most databases won't require any special casing but 
 I know that Oracle will require the addition of a trailing "DUAL" clause 
 (SELECT ... FROM DUAL)[1] and possibly some special casing of expressions 
 such as exists but there's already pre-existing logic for that[2]. If you 
 go with 1. this can be done by returning a backend specific string in 
 SQLCompiler.get_from_clause when self.query.alias_map is empty[3].

 In the end the call stack should be (assuming 1. is followed):

 Q.check(self, using):
   query = Query()
   query.add_annotations(self, '_check')
   query.set_values('_check')
   compiler = query.get_compiler(using=db)
   result = compiler.execute_sql(SINGLE)
   return bool(result[0])

 I hope this clears things up a bit!

 Cheers,
 Simon

 [0] https://github.com/django/django/pull/14494
 [1] 
 https://docs.oracle.com/cd/B19306_01/server.102/b14200/queries009.htm
 [2] 
 https://github.com/django/django/blob/ed3af3ff4b3cfb72de598f1b39a1028ba3826efb/django/db/models/expressions.py#L382-L389
 [3] 
 https://github.com/django/django/blob/ed3af3ff4b3cfb72de598f1b39a1028ba3826efb/django/db/models/sql/compiler.py#L797-L810

 Le mercredi 2 juin 2021 à 11:36:02 UTC-4, gaga...@gmail.com a écrit :

> Thanks for the thorough answer. I also realize now that it worked in 
> my app only because of another side effect when my instance was saved..
>
> I started to take a look at the ORM part where the check method should 
> be implemented as I'm not used to it. Shouldn't .check() be implemented 
> on 
> Q and not on Expression? Or are you including Lookup / Q in it?
>
> Then I'd guess it's just a matter of calling as_sql() from each part 
> and assemble them. Everythings we need seems to be done in Query and we 
> can't use it as it has to be linked to a model, so we would have to redo 
> it? Although as_sql needs a compiler which itself needs a query. I admit 
> I'm a bit lost in all those classes, everything seems to be too much 
> linked 
> to 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 

Re: #32749 PyMemcacheCache uses default_noreply=False although pymemcache recommends to set to True

['Adam Johnson' via Django developers (Contributions to Django itself)]

>
> I've gone through the documentation of pymencache and if I'm not wrong its
> nowhere written that it recommends  default_noreply to be set to True
>

It's covered in the "best practices" section, which is a list of their
recommendations:
https://pymemcache.readthedocs.io/en/latest/getting_started.html?highlight=noreply#best-practices

As a beginner to this project what do I supposed to do now, how can I fix
> this issue?
>

The conversation on the ticket has input from several people. We need to
decide what to do as a group. I've given my opinion.

On Mon, 31 May 2021 at 06:10, Nishant Sagar  wrote:

> I've gone through the documentation of pymencache and if I'm not wrong its
> nowhere written that it recommends  default_noreply to be set to True
>
> pymemcache documentation says noreply will not read errors returned from
> the memcached server.
>
> If a function with noreply=True causes an error on the server, it will
> still succeed and your next call which reads a response from memcached may
> fail unexpectedly.
>
> pymemcached will try to catch and stop you from sending malformed inputs
> to memcached, but if you are having unexplained errors, setting
> noreply=False may help you troubleshoot the issue.
>
>
> You can also look at ticket  #29887
>    -- Added a cache backend
> for pymemcache.
>
> It says that default_noreply has been set to false to make the behaviour
> consistent with the other backends and to allow the test suite to pass
> successfully. Currently django-pymemcache only sets the
> soft-deprecated serializer and deserializer options which have been
> superseded by serde.
>
> Note that pymemcache.serde.pickle_serde uses pickle.HIGHEST_PROTOCOL by
> default which is consistent with the configuration of
> the python-memcached backend.
>
>
> As a beginner to this project what do I supposed to do now, how can I fix
> this issue?
>
> Thank you
>
> --
> 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/760a175f-2111-4cf0-95f9-e735b204a8f4n%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/CAMyDDM2av3s0gK16dN3-r7kh8UkT7z1sARmcu60bCPdH59ZmoA%40mail.gmail.com.