Re: Make ManyToMany fields support "to_field".

[Anssi Kääriäinen]

On Tue, Jan 12, 2016 at 11:22 PM, Shai Berger  wrote:
> Personally, I'd like it better if add() could still be used with an explicit
> through model, provided that instances of the through model could be created
> using only the two FK values

+1

 - Anssi

-- 
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/CALMtK1G24qNwu1d2%2BFoBS%3DfyKw%3Dv%2Bv09kdani%2BmA_BrsqNrRwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Mat Clayton]

Hey guys,

+1 as well, this is really great work, on both patches!

Modifying the middleware stack mid request would be very useful for us.

We currently run 3 copies of the same code, with essentially different 
urls.py and middlewares loaded, each one is used to run a variation of the 
site, for example www/mobile web and api, and have slightly different 
requirements, which are handled in middlewares, for example api calls are 
authenticated by access tokens and www/mobile use cookies.

Ideally we'd love to consolidate our deployment into a single set of python 
web workers, but to date its been a little too complex to be worth it. We 
could however use the url dispatching patch and PR1 to write a middleware 
which could load in the necessary middleware stack based on the 
requirements of each request.

So my preference therefore would be for PR1 as I can see a few edge cases 
it would enable solutions for.

Mat 

On Friday, 8 January 2016 16:01:15 UTC, Florian Apolloner wrote:
>
> PR1 (allows changing the middlewares during the middleware run): 
> https://github.com/django/django/pull/5591
> PR2 (static middleware chain, seems simpler and probably the way to go): 
> https://github.com/django/django/pull/5949/ 
>
> On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner wrote:
>>
>> Haha, I was so focused on my previous approach that I forgot, that I 
>> could just chain them during setup (thanks knbk). So the question remaining 
>> now: Do we want to be able to change middlewares per request or not :D I 
>> guess I'll submit a second PR with the non-request usage.
>>
>> On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote:
>>>
>>> Mhm,
>>>
>>> I currently see no easy way to give *get_response* access to the list 
>>> of middlewares like done in 
>>> https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122
>>>  
>>> and following lines. The reason is that providing *get_response* at 
>>> setup/init time means it has to be one "static" method which is the same 
>>> for all requests. Aside from using a thread local or stashing the 
>>> middleware list on the request, this method has no way of getting access to 
>>> the current middleware chain. Any ideas?
>>>
>>> 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 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/6c61f7b1-0d8b-4cf4-8499-af167713cde6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make ManyToMany fields support "to_field".

[Shai Berger]

On Tuesday 12 January 2016 21:38:09 Luis Masuelli wrote:
> Currently, if I want to create a ManyToMany relationship, I'm stuck with
> two options:
> 
> 
>- Accept the by-default configuration. This will imply the inner table
>will have two fields based on the respective PKs.
>- Create a through-model. I will be able to specify two foreign keys,
>one for each table. I will lose the ability to cal .add and .delete.
> 
> Is there a chance to let the user specify custom to_field (and say,
> "from_field") in a M2M field? I think it would be a nice feature, as we
> already allow them in FK and O2O fields.

Personally, I'd like it better if add() could still be used with an explicit 
through model, provided that instances of the through model could be created 
using only the two FK values -- applying limitations only where they are 
actually needed on one hand, and keeping a clean separation between the 
default, implicit thruogh model on one hand, and all the customizations and 
configurations you can imagine on the other hand.

My 2 cents,
Shai.

Make ManyToMany fields support "to_field".

[Luis Masuelli]

Currently, if I want to create a ManyToMany relationship, I'm stuck with 
two options:


   - Accept the by-default configuration. This will imply the inner table 
   will have two fields based on the respective PKs.
   - Create a through-model. I will be able to specify two foreign keys, 
   one for each table. I will lose the ability to cal .add and .delete.

Is there a chance to let the user specify custom to_field (and say, 
"from_field") in a M2M field? I think it would be a nice feature, as we 
already allow them in FK and O2O fields.

-- 
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/ad91bad2-83a8-4884-a47e-34dc59646b67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostGres 9.5 Upsert

[bliyanage]

After thinking about it a bit, I think the only function that would really 
benefit from this would be the update_or_create.  If you're doing 
get_or_create you still need a second query to get the actual row.

On Friday, January 8, 2016 at 4:13:26 PM UTC-8, bliy...@rentlytics.com 
wrote:
>
> Hey Guys,
>
> Postgres 9.5 has added the functionality for UPSERT aka update or insert.  
> Any interest in aligning UPSERT on the db layer with the get_or_create or 
> update_or_create functionality in django?  Sounds like my company would be 
> interested in doing the work if the PR will get the traction.
>
> -Ben
>

-- 
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/858c3f77-a20c-413e-9e76-78435b589658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support `manage.py shell -c 'run_code_as_django()'`?

[Zach Borboa]

Nice to see that this was implemented.


$ cat myscript.py
import django
print(django.__version__)

$ python manage.py shell --command="import myscript"
1.10.dev2016011210



The --command option lets you pass a command as a string to execute it as 
Django, like so:

django-admin shell --command="import django; print(django.__version__)"


https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-option---command

-- 
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/e585499f-90b7-4a55-ba61-3c59130310b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Is there a reason these features cannot be added inside Django core?

[Luis Masuelli]

These features are pretty core-related.

1. Features from django-polymorphic. To mantain bw compatibility, the 
hierarchy parent could need to add something like polymorphic=True in the 
meta to this feature be activated.
2. Something like this snippet regarding Inlines in 
admin: https://djangosnippets.org/snippets/2032/, to be able to do this:

class A(models.Model):

b = OneToOneField('B')

class B(models.Model):

...

class AInlineAdmin(StackedInline):

model = A

class BAdmin(ModelAdmin):

inlines = (AInlineAdmin)

site.register(B, BAdmin)

Sometimes, doing this could be desirable as it was in my case.

Additionally, I don't know if it is a feature or a bug, but when I see the 
inline model section for a O2O field, the section is labeled as:

(verbose_name_plural)
(verbose_name) #1

Example (the Customer model admin has an inline to ContactDetails; the 
ContactDetails model has a direct O2O field to Customer; in this case I 
didn't use the reverse inline snippet I posted above, but the standard 
supported way):

Contacts Details
Contact Details #1

Even when there is only one element (since it is a O2O). Could a change be 
done for that case so these captions become...

(verbose_name)
(nothing)

only for the O2O case? (both in the standard way and -if you decide to 
support- the inverse inline)

-- 
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/a96740fe-c094-401b-82de-891836b6fc8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.