Re: [Feature Request] Shorthand syntax for filtering aggregations

[charettes]

Hello Tom,

Thanks for working on adding filter support to aggregate. I think adding
support for the SQL:2003 features on all aggregates by emulating it on
backends that don't support it using CASE makes a lot of sense[0].

As I've mentioned on your PR this is syntactic sugar I've been missing from
Django's conditional aggregation API since I was using 
django-aggregate-if[1]
before #11305 was fixed[2].

Now for the proposed syntax I understand you want to mimic the Queryset's
API by allowing filter()/exclude() to be chained but I don't think filter 
chaining
on aggregate is common enough to warrant the extra effort required to make 
it
work. As I've mentioned previously I'd advocate for a simple `filter` kwarg 
that
accepts a Q instance instead as it makes it easier to implement and emulate
the Case() fallback. This also makes the filter() vs filter().filter() for 
multi-valued
relationships subtleties a non-issue.

Mailbox.objects.annotate(
   read_emails=Count('emails', filter=Q(unread=False)),
   unread_emails=Count('emails', filter=Q(unread=True)),
   recent_emails=Count('emails', filter=Q(received_date__lt=one_week_ago)),
)


Cheers,
Simon

[0] http://modern-sql.com/feature/filter
[1] https://pypi.python.org/pypi/django-aggregate-if
[2] https://code.djangoproject.com/ticket/11305

Le mercredi 12 avril 2017 17:31:44 UTC-4, Tom Forbes a écrit :
>
> Hello,
> At the Djangocon sprints I wanted to add support for a postgres specific 
> syntax for filtering aggregations, which is quite simple: MAX(something) 
> FILTER (WHERE x=1).
>
> During this the sprints I was told that it would be good to support this 
> for all databases, and it can be done using the CASE syntax: MAX(CASE WHEN 
> x=1 THEN something END).
>
> Doing this with the ORM is quite verbose, it would be really nice to be 
> able to have a shorthand syntax for filtering aggregates that can use 
> database-specific syntax where available (the postgres syntax is faster 
> than the CASE syntax). I've made a proof of concept merge request that 
> implements this here:
>
> https://github.com/django/django/pull/8352
>
> I'd really like some feedback and to maybe have a discussion about what 
> the API could look like. Currently I went for adding `.filter()` and 
> `.exclude()` methods to the base Aggregate class. I like this approach as 
> it's close to the familiar queryset syntax but I understand there are 
> subtleties with combining them (I just AND them together currently). It's 
> also better to be consistent - if we can't support all of the queryset 
> filter() syntax then we shouldn't confuse people by having a filter method 
> that acts differently.
>
> An example of the API is this:
>
> Mailboxes.objects.annotate(
>read_emails=Count('emails').filter(unread=False),
>unread_emails=Count('emails').filter(unread=True),
>recent_emails=Count('emails').filter(received_date__lt=one_week_ago)
> )
>
>
> I'd really like some feedback on what the API should look like. Is filter 
> a good idea? Any feedback on the current merge request implementation is 
> appreciated as well, I'm fairly new to the Django expression internals. I 
> think I'm going the right way with having a separate FilteredAggregate 
> expression but I'm not sure.
>
> Many thanks,
> Tom
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d65367f-5e40-46a1-92c6-52e351002af2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[jpic]

Hello David,

Is it possible to try to use it as part of the Django fork you mention, 
instead of the app ?

I couldn't find any link on your github profile, your website and google 
but perhaps I've missed it.

Thanks !

Best
<3

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/36fb761d-76cf-4e23-a0e2-ca6d315d1182%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Jamesie Pic]

Ooops yes this is correct, it doesn't work in the advised file, apps.py

Thank you so much for your feedback, I need to ditch this patch just
find a way to make Django default usable date, time, image, relations
form fields useable ootb by marrying a JS framework.

Best
<3

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19jtK2EphhyeLL0NqBVg3JZ%3D%2Bbg8BScS9VwUVusx9Jh0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Info-Screen]

Wouldn't it be possible to implement case-insensitive usernames without 
loosing backwards compatibility, by checking the username iexact and only 
if there are multiple possibilities fall back to the old case-sensitive 
variant?

So something like this:

diff --git a/django/contrib/auth/base_user.py 
b/django/contrib/auth/base_user.py
index 34dd6ac2f2..748db8bf89 100644
--- a/django/contrib/auth/base_user.py
+++ b/django/contrib/auth/base_user.py
@@ -4,6 +4,7 @@ not in INSTALLED_APPS.
 """
 import unicodedata
 
+from django.core.exceptions import MultipleObjectsReturned
 from django.contrib.auth import password_validation
 from django.contrib.auth.hashers import (
 check_password, is_password_usable, make_password,
@@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
 return get_random_string(length, allowed_chars)
 
 def get_by_natural_key(self, username):
-return self.get(**{self.model.USERNAME_FIELD: username})
+username_field = self.model.USERNAME_FIELD
+
+# Try case-insensitive match of username.
+# If there are multiple possiblities fallback to case-sensitive 
lookup
+try:
+return self.get(**{username_field + '__iexac': username})
+except MultipleObjectsReturned:
+return self.get(**{username_field: username})
 
 
 class AbstractBaseUser(models.Model):

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Adam Johnson]

>
> About 1, if it's already working with a non-signal, how could it not work
> with a signal ? It is, after all, called from within formfield() in this
> implementation, so anything that's working today when formfield() is
> called, should work when formfield() emits a signal.
>

Signal handlers need to be registered before they get called. ModelForms
can be imported and thus instantiate their form fields by calling the model
fields' formfield() methods before your custom handler gets registered, so
they wouldn't be changed.

Btw another point for customization of forms would be the post_init form
signal as suggested here:
https://groups.google.com/forum/#!topic/django-developers/SviNiWy3Bjc

On 16 April 2017 at 10:58,  wrote:

> Hi Adam !
>
> About 1, if it's already working with a non-signal, how could it not work
> with a signal ? It is, after all, called from within formfield() in this
> implementation, so anything that's working today when formfield() is
> called, should work when formfield() emits a signal.
>
> For 2 & 3, yes, I know a lot of hacks exist. I just feel like I've been
> using them for the last decade, to every time replace the default field
> everywhere (forms, admin, drf, etc ...), it really looks like I'm fighting
> that I can't change the default myself.
>
> And this is systematically happening when I have a relation to another
> model, because the default widget does not work well when there is actual
> data in the relations, outside of the testing world where we have only a
> few instances.
>
> Am I really the only witness of this phenomenon ?
>
> <3
>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/ee180045-fd08-45bd-aced-
> 4a674da80912%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3S3vXBcaGQHkd--XNs7g1DGXhTLUdAyLB7pQ3j6JAPrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: take select request from django from

[Jeremy Spencer]

Hi Xristos,

This mailinglist is for developing the django framework itself, not for
getting help with your code. If you need help with your code please see the
Django Users group:
https://docs.djangoproject.com/en/dev/internals/mailing-lists/



-- 
Jeremy Spencer
www.jeremyspencer.me
www.linkedin.com/in/jeremylspencer
www.facebook.com/jeremyspencerllc

On April 16, 2017 at 4:03:49 PM, Xristos Xristoou (saxr...@gmail.com) wrote:

hello i have create a select django form with list of images for per user.

How to take that select request in my views.py ?

i have success only to create correct that select list but i need take that
select request but i dont know how.

models.py

class MyModel(models.Model):
user = models.ForeignKey(User, unique=True)
upload = models.ImageField(upload_to='upload')

views.py

   @login_required(login_url="login/")
def carlist(request):
Myform = MyModelForm(user=request.user)
return render(request,'about.html',{'Myform':Myform})

select django form :

class MyModelForm(ModelForm):
def __init__(self, *args, **kwargs):
# extract "user" from kwrags (passed upon form init)
if 'user' in kwargs:
self.user = kwargs.pop('user')
super(MyModelForm, self).__init__(*args, **kwargs)
# generate the choices as (display, value).
# Display is the one that'll be shown to user, value is
# the one that'll be sent upon submitting
# (the "value" attribute of )
choices =
MyModel.objects.filter(user=self.user).values_list('upload', 'id')
self.fields['upload'].widget = Select(choices=choices)

class Meta:
model = MyModel
fields = ('upload',)

html :

{% csrf_token %}
  {{ Myform}}

for example Myform now have a list of user images that is correct but after
from that i need the select images from the form.

can do it that with my code or not ?
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/42c47fb1-c0ff-445e-b052-48ea87ba0fe9%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACfg-bhDX6L8nJS2zKD9DFGksYW%2BRJvQHyF6_e45ZVF5d4vNqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

take select request from django from

[Xristos Xristoou]

 

hello i have create a select django form with list of images for per user.

How to take that select request in my views.py ?

i have success only to create correct that select list but i need take that 
select request but i dont know how.

models.py

class MyModel(models.Model):
user = models.ForeignKey(User, unique=True)
upload = models.ImageField(upload_to='upload')

views.py

   @login_required(login_url="login/")
def carlist(request):
Myform = MyModelForm(user=request.user)
return render(request,'about.html',{'Myform':Myform})

select django form :

class MyModelForm(ModelForm):
def __init__(self, *args, **kwargs):
# extract "user" from kwrags (passed upon form init)
if 'user' in kwargs:
self.user = kwargs.pop('user')
super(MyModelForm, self).__init__(*args, **kwargs)
# generate the choices as (display, value). 
# Display is the one that'll be shown to user, value is 
# the one that'll be sent upon submitting 
# (the "value" attribute of )
choices = MyModel.objects.filter(user=self.user).values_list('upload', 
'id')
self.fields['upload'].widget = Select(choices=choices)

class Meta:
model = MyModel
fields = ('upload',)

html :

{% 
csrf_token %}
  {{ Myform}}

for example Myform now have a list of user images that is correct but after 
from that i need the select images from the form.

can do it that with my code or not ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42c47fb1-c0ff-445e-b052-48ea87ba0fe9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[jpic]

Hi Adam !

About 1, if it's already working with a non-signal, how could it not work 
with a signal ? It is, after all, called from within formfield() in this 
implementation, so anything that's working today when formfield() is 
called, should work when formfield() emits a signal.

For 2 & 3, yes, I know a lot of hacks exist. I just feel like I've been 
using them for the last decade, to every time replace the default field 
everywhere (forms, admin, drf, etc ...), it really looks like I'm fighting 
that I can't change the default myself.

And this is systematically happening when I have a relation to another 
model, because the default widget does not work well when there is actual 
data in the relations, outside of the testing world where we have only a 
few instances.

Am I really the only witness of this phenomenon ? 

<3

>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee180045-fd08-45bd-aced-4a674da80912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.