Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'll drop it. Someone else can chime in if they want. Just to be clear, the work you all do on Django is much appreciated :) Thanks, Dave On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote: > On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > >> Yeah, I hope I'm not coming

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > Yeah, I hope I'm not coming off as being too pushy, but I'm just curious > why that is. Mariusz or Adam, did what I said about it being *more* than > just an alias for `filter().first()` make sense or am I missing something? > (Different beha

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

> I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which would work similarly to get_object_or_404 Personally I'm not a fan of it being in "shortcuts". It makes sense to me that the 404 ones are there because they are only useful in a request

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi I believe the main objection is against adding additional API to querysets. get_object_or_404 only converts DoesNotExist into a 404 exception and doesn't handle MultipleObjectsReturned. I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which w

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Fair enough. To me, the `get_or_none` behavior with multiple results would still be to raise an exception (so it is just like `get` in that sense). And that’s the reason I personally don’t just see it as a shortcut for `filter().first()` — I have (as I’m sure others have) made the mistake befor

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm also against adding get_or_none(), for the same reasons. Adding a method to shortcut something that can already be done doesn't seem worth it to me. On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak wrote: > I'm against it because it's already easily achievable and it's debatable > how it shou

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I'm against it because it's already easily achievable and it's debatable how it should behave with many results. IMO any new method would be confusing and in the case of unique filtering `get_or_none(unique_filters)` would be an alias for `.filter(unique_filters).first()`. To me, this is duplic

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hey Mariusz, thanks for the link — I found some other threads but not that one. Would you mind saying why you're personally against it (`get_or_none` specifically)? At least how I read that thread, there was more debate about how to add it than whether to add it at all, and then Cal sort of "ga

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

Hi, Adding `get_or_none()` was discussed several times and was always rejected. This thread has a nice summary. Personally, I'm still against it. Best, Mariusz -- You received this message because you are subscr

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

ly should allow to query only pks and >> > unique_together fields, so there will be no third state? >> >> To begin with - thats the place I dont like .get() at all. The fact that >> it might end up with multiple objects is a nuisance, but we cannot do >> much about i

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

up with multiple objects is a nuisance, but we cannot do > much about it for API compat reasons. Idea - if we want such a changed > behavior - maybe call it "unique_or_none()" to make the difference > clear? If its called .get_or_none() imho it is better to stick to .get() >

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

e, but we cannot do much about it for API compat reasons. Idea - if we want such a changed behavior - maybe call it "unique_or_none()" to make the difference clear? If its called .get_or_none() imho it is better to stick to .get() behavior regarding multiple objects (still raising). -

RE: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

developers@googlegroups.com [mailto:django-developers@googlegroups.com] On Behalf Of Jörg Breitbart Sent: Friday, June 24, 2022 11:56 AM To: django-developers@googlegroups.com Subject: Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first() @Dave Gaeddert Since you mentioned it - wha

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

on interpreter side, but thats really tiny compared to the db roundtrip (thus against the whole .get + helper runtime). Imho a chaining .checked() method on the manager/queryset is not a good idea, as it might create more API ambiguity - What should .checked() do, if it is n

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

ed to the db roundtrip (thus against the whole .get + > helper runtime). > > Imho a chaining .checked() method on the manager/queryset is not a good > idea, as it might create more API ambiguity - What should .checked() do, > if it is not followed by .get()? > > Cheers, j

Feature Idea: extend dumpdata command with django-filters

I recently had the need to dump a huge table using the Django dumpdata command but I only needed a subset of records base on some standard filter. I think there is already an external package for this, but for basic filtering I think it would be useful to have it integrated in Django simply add

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

thats really tiny compared to the db roundtrip (thus against the whole .get + helper runtime). Imho a chaining .checked() method on the manager/queryset is not a good idea, as it might create more API ambiguity - What should .checked() do, if it is not followed by .get()? Cheers, jerch -- You

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I don't like get() and catching exceptions. What I usually do is something like this: foo_list = Foo.objects.filter(x=x) if (len(foo_list) == 1): foo = foo_list[0] And if I need else, I can assign None or whatever. The advantage in this way is that you don't get an exc

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

A common idiom is also ``` try: foo = Foo.objects.get(x="foo") except Foo.DoesNotExist: foo = None ``` which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only argument on `get` that returns `None` if not found ``` foo = Foo.objects.get(x="foo", strict=False) # or foo =

Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

It is a common idiom to use `.filter(<...>).first()` as a replacement for `.get(<...>)` when `None` is wanted instead of an exception when no match is found. That works, but wouldn't the intention be more clear if that could be written as something like .checked(False).get(<...>) -- You recei

Re: Feature Idea: Allow setting session cookie name dynamically

Ah, thank you for explaining. I missed the point and the existing setting, sorry. Cheers, Maciej wt., 7 cze 2022 o 11:26 Florian Apolloner napisał(a): > Hi Maciej, > > You can already customize the cookie name via a setting. What this request > is asking is customization based on the request ob

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Maciej, You can already customize the cookie name via a setting. What this request is asking is customization based on the request object which is not that common. Did you check that you configured your applications correctly to use different cookie names (https://docs.djangoproject.com/en/

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Dan and Carlton, In my current company I am impacted by conflicting session cookie name. We have several internal tools built on Django, available in the internal network under the same top-level domain. The scope of session cookies apparently was set on more than one service to a wildcard. Maj

Re: Feature Idea: Allow setting session cookie name dynamically

Hi Carlton, thanks for the response. An external package might be useful, although the code majority of the code would be the copied SessionMiddleware code and the tiny changes to allow a dynamic cookie name, so my thoughts is that this might be "too small" for a published pypi package? But si

Re: Feature Idea: Allow setting session cookie name dynamically

Hey Dan. Thanks for following up here. Just to recap, my reasoning on the ticket was that it's quite a niche use-case. For me, just use the custom SessionMiddleware, or put that in a third-party package for multi-tenancy folks to maintain together. (Or so would be my opening thought... -- interes

Feature Idea: Allow setting session cookie name dynamically

Hi, Currently it's only possible to use a single session cookie, but it can be useful in a multi-tenant application to use multiple session cookies. To solve this we currently use our own, slightly modified SessionMiddleware class that we keep in sync with the official implementation and re-app

Re: Feature Idea for overwrite_default_connection context manager

That's a great idea, actually. Thank you On Wednesday, June 1, 2022 at 4:56:31 PM UTC+3 Adam Johnson wrote: > Modifying the connections object seems like the wrong way to approach > this, as it's not intended for mutation. Did you consider writing a > database router and th

Re: Feature Idea for overwrite_default_connection context manager

ps working > recently > > ValueError: Subqueries aren't allowed across different databases. Force > the inner query to be evaluated using `list(inner_query)`. > > But I'm wondering wouldn't it be useful to have that kind of manager in > the core Django

Feature Idea for overwrite_default_connection context manager

implementation of that context manager stops working recently ValueError: Subqueries aren't allowed across different databases. Force the inner query to be evaluated using `list(inner_query)`. But I'm wondering wouldn't it be useful to have that kind of manager in the core Django func

Re: A new feature idea

could be a good project for you to learn from developing as a third party package. —Adam On Mon, 25 Oct 2021 at 09:11, Ath Tripathi wrote: > I was seeing some website and came across a blog site, which have a small > section which show monthly visits and other things like that. > An idea

A new feature idea

I was seeing some website and came across a blog site, which have a small section which show monthly visits and other things like that. An idea came in my mind that to make a admin like page which show total website visits,modal read and write,update,deletion , many filters to filter on basis

Re: Idea

Am 21.10.21 um 13:31 schrieb Jet Ezra: Well, this looks like a cool attempt but still lacking the python part. I would like to update the DOM just with Python not anything like Javascript. From what I have read from the links above, I have realised that we are writing HTML that has already bee

Re: Idea

Well, this looks like a cool attempt but still lacking the python part. I would like to update the DOM just with Python not anything like Javascript. >From what I have read from the links above, I have realised that we are writing HTML that has already been covered up with JS, but in my issue, we a

Re: Idea

Check out htmx as a way to avoid needing JavaScript in your Django applications: https://htmx.org/ Example app: https://github.com/adamchainz/django-htmx On Sun, 19 Sept 2021 at 00:00, Jet Ezra wrote: > I know this may not be necessary at the moment because we are comfortable > depending on fro

Idea

I know this may not be necessary at the moment because we are comfortable depending on front-end frameworks, but I have my two ideas here: 1. what if django alone without any framework can be used to design progressive web apps, with routers that do not reload the page, we currently have one of

Re: Idea

Additionally, incorporating DRF [or any other 3rd party lib] into core would lock them into Django's release cycle. As for built-in REST/API features, Django provides `JsonResponse` already, so the main piece lacking is de/serialisers. The built in serializer framework is well suited to generat

Re: Idea

There are serializers and dictionaries built into the Django models system that I’ve had zero problems leveraging for building out JSON (or REST-like) objects for endpoint purposes. I personally believe integrating DRF into Django would needlessly bloat it. The two play together perfectly fine i

Re: Idea

For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t never felt like a great fit for Django projects. It’s very Rails-y. It would be amazing to have an official Django contrib package for REST. Never going to happen, but needs to be said. Best, Mike On Wed, Sep 15, 2021 at 4:4

Re: Idea

DRF remains an extension to Django. We don't want Django to depend on it. But you're free to set up a startproject template that includes the settings, and use that. https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template On Tue, 14 Sept 2021 at 08:44, abdul azeez

Idea

Pls can we make django come with django reest framework settings when you start a project -- 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, s

Re: need a good idea

Hi Check out the wiki page: https://code.djangoproject.com/wiki/SummerOfCode2021 Adam On Fri, 9 Apr 2021 at 05:05, fake man wrote: > Hello there , > can u please tell me what is a good idea or proposal for GSOC 2021 > > thanks > > -- > You received this message because

need a good idea

Hello there , can u please tell me what is a good idea or proposal for GSOC 2021 thanks -- 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 emai

Re: Django Project idea query

ck.) >> >> Kind Regards, >> >> Carlton >> >> >> On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote: >> >>> Hello All! >>> I am participating in GSOC 2021. I was looking at some of the project >>> lists and

Re: Django Project idea query

re you can get more feedback.) > > Kind Regards, > > Carlton > > > On Tuesday, 23 March 2021 at 10:48:34 UTC+1 khushik...@gmail.com wrote: > >> Hello All! >> I am participating in GSOC 2021. I was looking at some of the project >> lists and I am interested

Re: Django Project idea query

m wrote: > Hello All! > I am participating in GSOC 2021. I was looking at some of the project > lists and I am interested in the Django Benchmarking project idea. I would > like to know more about the tasks and operations involved in this project > idea. I am looking forward to cont

Django Project idea query

Hello All! I am participating in GSOC 2021. I was looking at some of the project lists and I am interested in the Django Benchmarking project idea. I would like to know more about the tasks and operations involved in this project idea. I am looking forward to contributing to the Django

Re: Advancing with the Triage & Review Team idea.

st do that.) >>> >>> BUT I’d like to resolve the second point here (it’s needed for the >>> examples given). >>> >>> I think it might need an edit to DEP 10… as per here: >>> >>> https://github.com/django/deps/blob/master/accepted

Re: Advancing with the Triage & Review Team idea.

UT I’d like to resolve the second point here (it’s needed for the >> examples given). >> >> I think it might need an edit to DEP 10… as per here: >> >> https://github.com/django/deps/blob/master/accepted/0010-new-governance.rst#id26 >> >> If so, I’m happy to

Re: Advancing with the Triage & Review Team idea.

hat up but I guess some pointer from the new TB > that it would be acceptable would be good. > > Kind Regards, > > Carlton > > > > > On 5 Oct 2020, at 15:46, charettes wrote: > > I like the idea but I don't feel comfortable vouching for it given my > confli

Re: Advancing with the Triage & Review Team idea.

new-governance.rst#id26> If so, I’m happy to type that up but I guess some pointer from the new TB that it would be acceptable would be good. Kind Regards, Carlton > On 5 Oct 2020, at 15:46, charettes wrote: > > I like the idea but I don't feel comfortable vouching for it giv

Re: Advancing with the Triage & Review Team idea.

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 bas

Advancing with the Triage & Review Team idea.

am. https://groups.google.com/g/django-developers/c/mUBWlG0-Jbw/m/0dtgwMwPAAAJ I began this but it ran into the DEP 10 changes, and I stopped working on it to let that go through. With the new TB in place, I'd like to bring that back now, granting PR Approval power, at least for Merge PRs. The ide

Re: Idea for Rollback Migration Rules

ng this. Back to the VCS idea and as an aside to Django development: Looking at the git docs, a post-checkout script could compare the two branches and provide a warning about any change to the migrations in the working tree. Looks like others have thought down the same lines: - https://st

Re: Idea for Rollback Migration Rules

See if this solves part of the problem https://github.com/lorinkoz/django-unmigrate -- 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

Re: Idea for Rollback Migration Rules

RunPython migration operations would not be safe to run as the code has changed underneath. On Friday, 19 June 2020 23:15:31 UTC+10, Alexander Lyabah wrote: > > I just have a very small idea, maybe I can get a feedback about it here. > > What if db will store not only migration name but

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

r checkin" if everything looks good, or >> leave comments for improvement and mark the ticket as "Patch needs >> improvement". >> >> Thanks for any help. >> >> - David >> >> On Tuesday, October 1, 2019 at 11:06:15 PM UTC-7, David

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

e: >> >> Trac ticket created: https://code.djangoproject.com/ticket/30828 >> >> On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote: >>> >>> Hey David, >>> I like this idea, while I don’t think the use case is common there have

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

d Foster wrote: > > Trac ticket created: https://code.djangoproject.com/ticket/30828 > > On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote: >> >> Hey David, >> I like this idea, while I don’t think the use case is common there have >> been a

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Trac ticket created: https://code.djangoproject.com/ticket/30828 On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote: > > Hey David, > I like this idea, while I don’t think the use case is common there have > been a few times where I’ve needed this and got around it by

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Hey David, I like this idea, while I don’t think the use case is common there have been a few times where I’ve needed this and got around it by creating/modifying the through model in bulk. Having a method that does this would be good IMO. Unless anyone has strong opinions against this then can

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

write and add a *bulk_associate()* method to Django. I also > propose to add a paired *bulk_disassociate()* method. > > *1. Does this sound like a good idea in general?* > > > In more detail, I propose adding the specific APIs, importable from > *django.db*: > &

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

What if we could do something like the following instead: > > bulk_associate(M1.m2_set, [(m1, m2), ...]) > # --- OR --- > bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...]) > > I propose to write and add a *bulk_associate()* method to Django. I also > propose to add a paired

Feature idea: bulk_associate: Add ManyToMany relationships in bulk

thod. *1. Does this sound like a good idea in general?* In more detail, I propose adding the specific APIs, importable from *django.db*: M1 = TypeVar('M1', bound=Model) # M1 extends Model M2 = TypeVar('M2', bound=Model) # M2 extends Model def bulk_associate(

Re: Queries about the project idea Improving the Less Popular Backends

Hello, Thanks for your reply. I will start contributing patches now. Regards, Dingfan -- 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, se

Re: Queries about the project idea Improving the Less Popular Backends

community that ypu are capable to complete what you >> are proposing. >> >> Cheers! >> >> Asif >> >> On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote: >>> >>> Hello guys, >>> >>> I am year 4 students

Re: Queries about the project idea Improving the Less Popular Backends

core team and the community that ypu are capable to complete what you > are proposing. > > Cheers! > > Asif > > On Monday, April 8, 2019 at 5:24:06 PM UTC+6, Dingfan Zhao wrote: >> >> Hello guys, >> >> I am year 4 students in Singapore and I would like to

Re: Queries about the project idea Improving the Less Popular Backends

his summer. The project idea that I am interested in is Improving > the less popular backends. However, the project description is kind of > vague and I am not able to catch the exact requirements for this project. > > In my view, the key for this project is to build some features for less

Queries about the project idea Improving the Less Popular Backends

Hello guys, I am year 4 students in Singapore and I would like to contribute to Django in GSoC this summer. The project idea that I am interested in is Improving the less popular backends. However, the project description is kind of vague and I am not able to catch the exact requirements for

Re: GSOC 19 PROPOSAL IDEA

rds, Carlton On Thursday, 14 March 2019 01:03:33 UTC+1, Chinmay Relkar wrote: > > Hi, >My name is Chinmay Relkar. I'm a final year undergrad from India. > This is about my GSOC proposal idea. > >While playing with django, I've always come across t

GSOC 19 PROPOSAL IDEA

Hi, My name is Chinmay Relkar. I'm a final year undergrad from India. This is about my GSOC proposal idea. While playing with django, I've always come across the absence of bidirectional ManyToMany feature ticketed at *code.djangoproject.com/ticket/897 <http://code.djan

Re: GSoC 2019 Project Idea

it's sounds like the > sort of functionality that we prefer to live in third-party apps, rather > than in Django itself. > (It sounds like a good enough idea — there are plenty of Jekyll, or other > static, sites out there, but just not something for core.) > > As I just

Re: GSoC 2019 Project Idea

Hi Parth. I'm guessing this would be out of scope for Django: it's sounds like the sort of functionality that we prefer to live in third-party apps, rather than in Django itself. (It sounds like a good enough idea — there are plenty of Jekyll, or other static, sites out there, bu

GSoC 2019 Project Idea

Hey, I had a project idea for GSoC. I wanted to make a tool which will help to port static projects like Jekyll to Django directly. I am still thinking about the details of the idea. But I want to know: - is this idea feasible/useful? - Does there already exist a similar tool for this

Re: GSoC Idea

Hey, can you elaborate on what your idea is? On Thursday, January 31, 2019 at 4:54:36 PM UTC+5:30, gaurav jain wrote: > > from django.db import models > from django.contrib.auth.models import User > > class CommenInfo(models.Model): > archived = models.BooleanF

GSoC Idea

from django.db import models from django.contrib.auth.models import User class CommenInfo(models.Model): archived = models.BooleanField(default=False) created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True) def delete(self): se

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

You could probably also just monkey patch like so: from django.db.models import Manager, QuerySet Manager.ident = QuerySet.ident = lambda self, pk: self.get(pk=pk) On Wed, Nov 7, 2018 at 3:33 PM C. Kirby wrote: > I bit the bullet and put together a small app to handle this, with maybe > even le

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I bit the bullet and put together a small app to handle this, with maybe even less typing. It monkey patches all installed models so you can run Model.ident_(pk) Can be found at https://github.com/ckirby/django-model-ident Chaim -- You received this message because you are subscribed to the Go

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

This is something I've also experimented while working with a shell, I often mislead the .get(pk), with .get(pk=pk), but only at the shell, not in the views or other places (not sure why). For that, I'm -1 to to include it in the core, and possible the best place is a third package app like djan

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

When experimenting with code in the shell, debugging or troubleshooting, I personally tend to do a lot of get. I know some object cause issue so I try to get them to poke them and see what's the problem. When trying to get them, if I have the id, I always try to type Model.objects.get(id). Sometim

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I still don't understand the problem this is solving; is typing "pk=" (or "id=") that much of a burden? Or that frequently left out by accident? As it stands, I agree with Adam that this adds implementation complexity (including potential future implementation complexity, as Ivan noted) and prolif

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I feel this would be a good addition to just .get(), I’ve wanted this while working with the shell. Model.objects.get(pk) feels very natural to me, and the common Model.objects.get(pk=pk) always felt overly verbose. On 5 November 2018 at 22:37:52, Josh Smeaton (josh.smea...@gmail.com) wrote: I

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I'm in the same boat as Simon - I've wanted this many times in the last few months, but only when working at the shell. I'd be +1 for get and -1 for filter also. On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote: > > As I've mentioned on the ticket I've been wishing get(pk) could tra

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

on of charfield and integerfield as your key (primary or > foreign doesn't matter): what does .get(('string', 123)) mean? > .get(string=123) or .get(field1='string', field2=123)? > > Actually, I think passing pairs isn't such a good idea either, bu

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

.get(string=123) or .get(field1='string', field2=123)? Actually, I think passing pairs isn't such a good idea either, but I can see some benefits over using dicts or unpacked args. (Assuming Q objects are not desired, for whatever reason.) I'd prefer being sure which fields c

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

Count me as -1 too, it doesn't seem worth it to me to save the 3 characters 'pk='. It would increase complexity of implementation and complexity of comprehension ("two ways to do it"). On Wed, 31 Oct 2018 at 23:00, Ian Foote wrote: > I'm not in favour of this, it's too implicit for my liking and

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I'm not in favour of this, it's too implicit for my liking and I don't think any gains outweigh the increased complexity of implementation. Ian On Wed, 31 Oct 2018 at 19:04, charettes wrote: > My main concern with allowing extra args and kwargs to be mixed with the > proposed > pk arg notation

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

My main concern with allowing extra args and kwargs to be mixed with the proposed pk arg notation is that it would allow lookups such as get(Q(is_active=True), pk) Simon Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit : > > *I'm not convinced this would be as useful for `filter()` th

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

*I'm not convinced this would be as useful for `filter()` though as I don't* *recall wanting to retrieve a set of objects matching a value I know will* *be unique.* The .filter() could be used for update e.g.: Mymodel.objects.filter(1).update(key=value) This is also bringing consistency in the c

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

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

Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

Hi, I'm creating this topic to see if there is interest to implement positional arguments in queryset filtering. Current situation Currently the only way to use positional arguments to filter can be either: - Passing a single or multiple Q objects: MyClass.objects.filter(Q(key=valu

Re: Feature idea: forms signals

Hi JP, That's a good point, sorry I didn't make it clear. The fork is installed from within the requirements file but you can also see it here, on the ticket_27923 branch: https://github.com/seddonym/django/tree/ticket_27923 I've updated the README to help. I'd be interested to hear if anyone

Re: Feature idea: forms signals

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 Goog

Re: GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

; >> I have been working on understanding previous works related to composite >> ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on >> Fields API/RelationField API improvement/clean ups etc. >> >> Is it a good idea to prepare something like this for gs

Re: GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

UTC-4, Asif Saifuddin wrote: > > Hi, > > I have been working on understanding previous works related to composite > ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on > Fields API/RelationField API improvement/clean ups etc. > > Is it a good idea to pr

GSOC 2017 Project Idea - Improve ORM by introducing real VirtualField and related field clean up

Hi, I have been working on understanding previous works related to composite ForeiegnKey/PrimaryKey support/ VirtualField support, works/tickets on Fields API/RelationField API improvement/clean ups etc. Is it a good idea to prepare something like this for gsoc this year? I have also trying

Re: Feature idea: forms signals

I've put together a brief proof of concept here: https://github.com/seddonym/formsignals It demonstrates what you could do with post_init, post_clean and post_save signals, which I've also implemented in a fork of Django (no test coverage or documentation yet though). The concept it demonstrat

Re: Feature idea: forms signals

Hello, > On 10 Mar 2017, at 10:25, Florian Apolloner wrote: > > On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote: > What are the next steps? Shall I create a pull request, or does this need > more consensus first? > > Imo absolutely more consensus, especially (to minimize th

Re: Feature idea: forms signals

On Friday, March 10, 2017 at 10:12:54 AM UTC+1, David Seddon wrote: > > What are the next steps? Shall I create a pull request, or does this need > more consensus first? > Imo absolutely more consensus, especially (to minimize the work for you), please do not just suggest the signals but also t

Re: Feature idea: forms signals

I've created a ticket for this here: https://code.djangoproject.com/ticket/27923#ticket What are the next steps? Shall I create a pull request, or does this need more consensus first? David On Wednesday, 8 March 2017 17:46:12 UTC, Melvyn Sopacua wrote: > > On Wednesday 08 March 2017 18:18:26

Re: Feature idea: forms signals

On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote: > On Monday 06 March 2017 10:10:41 David Seddon wrote: > > Hi all, > > > > One thing I've always found challenging with Django is to adjust the > > functionality of forms from other apps. An example might be to add > > an extra field to a

  1   2   3   4   >