Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

2017-03-21 Thread Alexander Hill
Here's a little bit more historical discussion on the topic:
*https://groups.google.com/d/topic/django-developers/uWe31AjzZX0/discussion
*

On Wed, 22 Mar 2017 at 05:57 Russell Keith-Magee 
wrote:

> On Tue, Mar 21, 2017 at 2:37 PM, Adam Johnson  wrote:
>
> It does seem like a somewhat arbitrary historical restriction. Collin's
> PoC change is surprisingly small and simple.
>
> Seems like it would be fine if Django allowed add() and let any errors
> about missing data bubble-up.
>
>
> As the person who *made* the “somewhat arbitrary historical restriction”…
> :-)
>
> Honestly - the reason it was made was scope creep.
>
> I was trying to land Eric’s work on #6095, which was already moderately
> complex. Nobody disagreed that adding an object to an m2m with a through
> model was a *bad* idea - there were just a few design decisions that had to
> be made. But if we made those decisions, #6095 was going to take *another*
> couple of months to land; the perfect being the enemy of the good, we
> decided to limit scope and land “simple” m2m add, and revisit the issue
> later.
>
> I guess now is “later”… :-)
>
> Yours,
> Russ Magee %-)
>
> --
> 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/CAJxq849m632K%3DaMfXGBtF%3DhMXFS9ujzU6xfUzNxSRkkN_UrkqQ%40mail.gmail.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/CA%2BKBOKyNyc1_mcUQiQEiv2FanRLHfU6tR3Sxcv30CcLWgWEqQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding generated common table expressions

2017-03-21 Thread Ashley Waite
Here's the code changes I've made, noting that some of them were to shove 
in a generalised VALUES clause that mocks being a queryset, so that it 
plays with the same interface.

https://github.com/django/django/compare/master...ashleywaite:cte-dev#files_bucket

I've had a glance at cte-trees/cte-forest and once general CTEs are worked 
out expanding that to include recursive CTEs wouldn't be too difficult, and 
that would greatly simplify the implementation of cte-forest to the extent 
that it might be viable as a django data/reference type.

- Ashley

On Saturday, March 18, 2017 at 8:28:53 PM UTC+11, Josh Smeaton wrote:
>
> Thanks for bringing this up Ashley, and for all of the detail you 
> provided. I'd certainly like to see CTEs make their way into Django, 
> provided we could come up with a nice enough API. From the look of it, 
> you've already got something that works with an okay API so I'm hopeful.
>
> I'd be very interested in seeing your POC too if you're able to share.
>
> From looking very briefly at django-cte-trees it doesn't aim to support 
> user defined CTEs for anything other than recursive queries. I'd be 
> interested in seeing, as part of a DEP, how CTE inclusion in django core 
> could support the cte-trees project from an API perspective.
>
> On Friday, 17 March 2017 22:28:17 UTC+11, Ashley Waite wrote:
>>
>> Hey all,
>>
>>
>> I'd like to suggest adding Common Table Expression (CTE) query generation 
>> as a feature to Django.
>>
>> I've been working on a project that required manipulation of many records 
>> at once, and as with many ORMs found that this wasn't an ideal use-case in 
>> Django. As the rest of our code base and related projects are in Django, 
>> there was a strong preference to find a way to do it and keep to the same 
>> model-is-the-truth design.
>>
>> I first did this by writing some hackish functions using raw querysets 
>> and generating my own CTE based queries, but it lacked ideal flexibility 
>> and maintainability. So I've now written some modifications into my Django 
>> to do this in a more Django-esque way and think that this functionality 
>> would be beneficial within the project itself, but am unsure exactly where 
>> to start the conversation about that.
>>
>>
>> *Why generate CTE based queries from querysets?*
>>
>> By allowing querysets to be attached to each other, and setting 
>> appropriate WHERE clauses, arbitrary and nested SQL queries can be 
>> generated. Where the results of the queries are only necessary for the 
>> execution of following queries this saves a very substantial amount of time 
>> and database work. Once these features exist, other functionality can also 
>> transparently use these to generate more efficient queries (such as large 
>> IN clauses).
>>
>> This allows several powerful use cases I think Django would benefit from:
>>
>>
>> *Large 'IN' clauses*, can be implemented as CTEs reducing expensive 
>> lookups to a single CTE INNER JOIN. For sets of thousands to match from 
>> tables of millions of records this can be a very substantial gain.
>>
>>
>> *Composite 'IN' conditions,* where multiple fields must match and you're 
>> matching against a large set of condition rows. In my usage this was "where 
>> the md5/sha hashes match one of the million md5/sha tuples in my match 
>> set". This is simply a CTE JOIN with two clauses in the WHERE.
>>
>>
>> *Nested data creation*, where the parent doesn't yet exist. Django 
>> doesn't currently do this as the primary keys are needed, and this makes 
>> normalised data structures unappealing. Using INSERTs as CTEs that supply 
>> those keys to following statements means that entire nested data structures 
>> of new information can be recreated in the database at once, efficiently 
>> and atomically.
>>
>>
>> *Non-uniform UPDATE*s, such that a modified set of objects can all be 
>> updated with different data at the same time by utilising a CTE values 
>> statement JOINed to the UPDATE statement. As there's currently no way to do 
>> this kind of bulk update the alternative is to update each instance 
>> individually, and this doesn't scale well.
>>
>> These could also be used with aggregations and other calculated fields to 
>> create complex queries that aren't possible at the moment.
>>
>>
>> *What my PoC looks like*
>>
>> With another mildly hackish PoC that creates a VALUEs set from a 
>> dict/namedtuple which can be used to provide large input data, my present 
>> modified version syntax looks a bit like this (not perfect queries):
>>
>> class Hashes(models.Model):
>> md5 = models.UUIDField(verbose_name="MD5 hash (base16)", db_index=True)
>> sha2 = models.CharField(max_length=44, null=True, verbose_name="SHA256 
>> hash (base64)")
>>
>> # Mock QuerySet of values
>> q_mo = Hashes.as_literal(input_hashes).values("md5", "sha2")
>> # A big IN query
>> q_in = Hashes.objects.attach(q_mo).filter(md5=q_mo.ref("md5"))
>>
>> # Matched existing values with composite 'IN' (where 

Re: Adding generated common table expressions

2017-03-21 Thread Ashley Waite
CTE Forest is a specific use case of CTEs to store self-referential tree 
data sets.

It's quite a different use to what I'm proposing, though its implementation 
might become simpler if Django is generally CTE aware.

- Ashley

On Saturday, March 18, 2017 at 6:59:57 PM UTC+11, Matthias Kestenholz wrote:
>
> Hi, 
>
> On Sat, Mar 18, 2017 at 12:49 AM, Tim Graham  > wrote: 
> > Hi, I don't know anything about CTE, but did you see this third-party 
> > package? https://github.com/petrounias/django-cte-trees -- It seems to 
> be 
> > PostgreSQL only. 
>
> Just chiming in to point out a maintained and up-to-date friendly fork 
> of the project above: 
> https://github.com/matthiask/django-cte-forest 
>
> Ashley, is your PoC available somewhere? Is your implementation in any 
> way similar to the implementation in 
> django-cte-trees/django-cte-forest? 
>
> Thanks, 
> Matthias 
>

-- 
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/742681c3-85e7-4420-89c8-834c33690990%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding generated common table expressions

2017-03-21 Thread Ashley Waite
I'm nesting the query generators as they currently exist and adding 
awareness of that nesting into another compiler, so that queries that 
reference other models, contain annotations, etc should still in theory 
work fine.

I do agree that the best method would be to generalise this to incorporate 
subqueries as well, but I considered those to be a subset of general CTE 
queries which can effectively be any valid query.

With some minor modifications to the existing INSERT/UPDATE/SELECT 
compilers via subclassing I think that subqueries as special cases of 
general statements that have some restrictions is probably the easiest 
route.
My current fiddling has changed INSERT/UPDATE to have returning clauses 
using subclassed compilers:
https://github.com/ashleywaite/django/blob/cte-dev/django/db/models/sql/subqueries.py#L174-L209
https://github.com/ashleywaite/django/blob/cte-dev/django/db/models/sql/compiler.py#L1283-L1321

Such that regular non-RETURN aware uses aren't impacted by that code - but 
I suspect that making INSERT and UPDATE be RETURN aware and lazily executed 
as a default case might be better, and more consistent with the way that 
SELECT based querysets work.

I'm using a workaround to feed in VALUES clauses, which again I think would 
probably be better as a proper QuerySet subclass that is used by INSERT 
statements and CTEs alike.
The language is a bit confusing because .values() is a method in Django, so 
mock querysets that define literal values intended to generate a VALUES 
clause don't really have a good name, but they would introduce some 
consistency as that's what INSERT statements are doing, and what 
non-uniform UPDATEs and composite IN style queries would want to do.

The leading CTE WITH clauses I'm generating are done via it's own compiler 
as well, such that only queries that are aware of having such queries 
attached will generate them:
https://github.com/ashleywaite/django/blob/cte-dev/django/db/models/sql/compiler.py#L1324-L1374

These could fairly easily be adapted to use a more general case for 
attaching one query to another, as my relatively haskish PoC was mostly to 
show that it can be done without substantial complexity, and that 
modification of other systems to better incorporate these patterns is 
probably a good idea.

As they stand now, CTEs used in the way I am using them could with little 
effort be modified to support aggregations, and annotations on the base 
query to pull in values from complex generated CTE's is probably the ideal 
way to perform some multi-table calculations.

- Ashley

On Monday, March 20, 2017 at 6:23:44 PM UTC+11, Anssi Kääriäinen wrote:
>
> +1 for the INSERT and UPDATE parts.
>
> For the .attach() method, I wonder if it would be better to work on having 
> generic subquery support in the ORM instead of targeting CTEs specifically. 
> From Django's perspective there isn't any big difference between:
> WITH fooquery AS (SELECT * FROM foo WHERE ...)
> SELECT * FROM baz JOIN fooquery ON ...
> and
> SELECT * FROM baz JOIN (SELECT * FROM foo WHERE ...) fooquery ON ...
>
> The great thing about the subquery form is that it works on every 
> database, and to my knowledge the subquery support is surprisingly standard 
> on all database Django needs to care about.
>
> If we want full support for either of the above cases, then we need some 
> way to tell to the Django's ORM what the fooquery (either as subquery or 
> with CTE) produces. For simple cases this won't be complex (say, for 
> .values() it's just a list of expressions), but what to do when the 
> subquery/CTE contains .select_related() for example? Then we'd have a 
> situation where the subquery produces a list of expressions but those 
> expressions might refer to different models in the CTE.
>
> So, the starting point should be to allow only "simple" queries in 
> .attach(). This means that the attached query must be either .values() 
> queryset, or a queryset containing expressions from single model only (no 
> .extra(), .annotate() or select_related() added). In addition I think 
> .attach() should support subqueries instead of using only CTEs. We get 
> support on every backend instead of PostgreSQL only for pretty much the 
> same amount of effort.
>
>  - Anssi
>
> On Saturday, March 18, 2017 at 11:28:53 AM UTC+2, Josh Smeaton wrote:
>>
>> Thanks for bringing this up Ashley, and for all of the detail you 
>> provided. I'd certainly like to see CTEs make their way into Django, 
>> provided we could come up with a nice enough API. From the look of it, 
>> you've already got something that works with an okay API so I'm hopeful.
>>
>> I'd be very interested in seeing your POC too if you're able to share.
>>
>> From looking very briefly at django-cte-trees it doesn't aim to support 
>> user defined CTEs for anything other than recursive queries. I'd be 
>> interested in seeing, as part of a DEP, how CTE inclusion in django core 
>> could support the cte-trees 

Django 1.11 release candidate 1 released

2017-03-21 Thread Tim Graham
We've made the final (hopefully) release on the way to Django's next major 
release, Django 1.11! Check out the blog post:

https://www.djangoproject.com/weblog/2017/mar/21/django-111-rc-1-released/

-- 
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/6c141879-6adb-4234-b5ea-66c1fcbf0efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: To keep or not to keep: logging of undefined template variables

2017-03-21 Thread Luke Plant
My general policy is that warnings should only be logged if there is a 
good way to silence them. A good way means:


1) fix the bug which is causing them (only applies if there is genuinely 
a bug or bad practice that should be fixed)


2) disable the warning in a fine tuned way i.e. you can indicate, 
without much work or hackiness, *this* instance generating the warning 
is actually fine.


Otherwise, these warnings are useless or worse - people often:

* just turn off all warnings of this type because they are too noisy (so 
they become useless)


* or end up turning off even more than necessary (hurting the project)

* or miss genuine issues because of the noise.

It sounds like these warnings are of the unhelpful kind.


For implementing option 2, the only thing I could think of is extending 
the template syntax with something that indicates you are expecting the 
value to be missing e.g.:


   {% if foo? %}

   {{ foo? }}

This would clearly be a big change though.


Luke


On 16/03/17 22:03, Tim Graham wrote:
Ticket #18773 [0] added logging of undefined template variables in 
Django 1.9 [1], however, I've seen several reports of users finding 
this logging more confusing than helpful. For example, admin templates 
log errors about missing is_popup variables [2] which is how the 
template are designed (is_popup is only in the contexts of pop ups) 
and the TECHNICAL_404_TEMPLATE also logs errors without any obvious 
solution about how to prevent that [3].


I'm thinking it might be better to remove this noisy, generally 
unhelpful logging. What do you think?


[0] https://code.djangoproject.com/ticket/18773
[1] 
https://github.com/django/django/commit/dc5b01ad05e50ccde688c73c2ed3334a956076b0

[2] https://groups.google.com/d/topic/django-users/6Ve9dcv23sI/discussion
[3] https://code.djangoproject.com/ticket/26886
--
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/a428f373-ef0c-4575-8a84-69a4beda154c%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/56aa2380-64a0-aa39-d9ec-5d6124f4ebde%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

2017-03-21 Thread Russell Keith-Magee
On Tue, Mar 21, 2017 at 2:37 PM, Adam Johnson  wrote:

> It does seem like a somewhat arbitrary historical restriction. Collin's
> PoC change is surprisingly small and simple.
>
> Seems like it would be fine if Django allowed add() and let any errors
>> about missing data bubble-up.
>>
>
As the person who *made* the “somewhat arbitrary historical restriction”…
:-)

Honestly - the reason it was made was scope creep.

I was trying to land Eric’s work on #6095, which was already moderately
complex. Nobody disagreed that adding an object to an m2m with a through
model was a *bad* idea - there were just a few design decisions that had to
be made. But if we made those decisions, #6095 was going to take *another*
couple of months to land; the perfect being the enemy of the good, we
decided to limit scope and land “simple” m2m add, and revisit the issue
later.

I guess now is “later”… :-)

Yours,
Russ Magee %-)

-- 
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/CAJxq849m632K%3DaMfXGBtF%3DhMXFS9ujzU6xfUzNxSRkkN_UrkqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: HMVC implementation on django

2017-03-21 Thread Asif Saifuddin
Hi,
This question should be posted in django-users mailing list, as this list 
is for discussing about django internals.

Anyway, you could read the answer 
here 
http://stackoverflow.com/questions/31914098/djangos-equivalent-of-php-codeigniters-hmvc

Thanks

On Tuesday, March 21, 2017 at 7:20:58 PM UTC+6, Shiwam Pd wrote:
>
> Can django be like HMVC framework? 
>
>

-- 
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/39486205-5bd0-49cd-aea2-b060cf076c28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


HMVC implementation on django

2017-03-21 Thread Shiwam Pd
Can django be like HMVC framework? 

-- 
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/e1a741a5-3b9b-40cb-b6e2-375f2198e783%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Any interest in integrating Django Admin Sortable into core?

2017-03-21 Thread Brandon Taylor
Morning Adam,

I can certainly refactor jQuery-UI out of this code. Aside from performance 
improvements, the core of django-admin-sortable has remained almost the 
same for about 5 years - or longer... I can't even remember when I created 
it - I'm getting old!

Let me see what I can do in that regard, if you feel it would raise the 
chances of it getting pulled in?

On Tuesday, March 21, 2017 at 3:16:09 AM UTC-4, Adam Johnson wrote:
>
> Hi Brandon,
>
> Thanks for offering to contribute.
>
> I'm not particularly familiar with the admin but from a quick look I see 
> django-admin-sortable uses jQuery UI to support its functionality, whilst 
> contrib.admin doesn't use it. I don't think there's a strict policy on 
> whether new JS libraries should be integrated in contrib.admin but I can 
> imagine adding jQuery UI being a little complicated since it could break 
> for users who have already added jQuery UI themselves.
>
> Also from experience, if something gets merged to core it can slow down 
> its development. Tying the releases to Django's means that improvements are 
> slower to be released and this can even discourage contributions. If it was 
> up to me I'd devolve some of the apps in contrib into separate packages :)
>
> Adam
>
> On 20 March 2017 at 20:56, Brandon Taylor  > wrote:
>
>> Hello Django Developers,
>>
>> I've been a longtime user (since before the "newforms-admin" branch) and 
>> proponent of Django and am the creator and maintainer of Django Admin 
>> Sortable: https://github.com/iambrandontaylor/django-admin-sortable
>>
>> I've been fortunate enough in my career to have been able to do Django 
>> full-time as the former Lead Developer of The Texas Tribune, a Principal 
>> Developer at USA Today and as a Technical Architect at Inmar in North 
>> Carolina. So thank you, for such a great framework and for making so many 
>> years of my life so enjoyable as a developer.
>>
>> If you're not familiar with Django Admin Sortable, it's a mixin-based way 
>> to add drag-and-drop ordering to just about any kind of object in Django 
>> Admin - something I needed to do on basically every Django project I ever 
>> built. Other popular frameworks such as Keystone.js have drag-and-drop 
>> ordering baked into them, so why not Django? I'm hoping you could take what 
>> I've done and not only integrate it, but make it better in ways I couldn't. 
>> I personally think it would be awesome to simply be able to add a Meta 
>> property to a model to enable this functionality without having to inherit 
>> the Mixin.
>>
>> It would be an honor to be able to contribute to Django's core 
>> functionality after so many years of using the framework. I'm hopeful 
>> you'll consider my proposal.
>>
>> Kindest Regards,
>> Brandon Taylor
>>
>> -- 
>> 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 post to this group, send email to django-d...@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/389733b0-cccf-4359-9cc7-0d6883f9d495%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/b97a6e05-89dc-413e-bdd4-3114a5e9ab59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Any interest in integrating Django Admin Sortable into core?

2017-03-21 Thread Adam Johnson
Hi Brandon,

Thanks for offering to contribute.

I'm not particularly familiar with the admin but from a quick look I see
django-admin-sortable uses jQuery UI to support its functionality, whilst
contrib.admin doesn't use it. I don't think there's a strict policy on
whether new JS libraries should be integrated in contrib.admin but I can
imagine adding jQuery UI being a little complicated since it could break
for users who have already added jQuery UI themselves.

Also from experience, if something gets merged to core it can slow down its
development. Tying the releases to Django's means that improvements are
slower to be released and this can even discourage contributions. If it was
up to me I'd devolve some of the apps in contrib into separate packages :)

Adam

On 20 March 2017 at 20:56, Brandon Taylor  wrote:

> Hello Django Developers,
>
> I've been a longtime user (since before the "newforms-admin" branch) and
> proponent of Django and am the creator and maintainer of Django Admin
> Sortable: https://github.com/iambrandontaylor/django-admin-sortable
>
> I've been fortunate enough in my career to have been able to do Django
> full-time as the former Lead Developer of The Texas Tribune, a Principal
> Developer at USA Today and as a Technical Architect at Inmar in North
> Carolina. So thank you, for such a great framework and for making so many
> years of my life so enjoyable as a developer.
>
> If you're not familiar with Django Admin Sortable, it's a mixin-based way
> to add drag-and-drop ordering to just about any kind of object in Django
> Admin - something I needed to do on basically every Django project I ever
> built. Other popular frameworks such as Keystone.js have drag-and-drop
> ordering baked into them, so why not Django? I'm hoping you could take what
> I've done and not only integrate it, but make it better in ways I couldn't.
> I personally think it would be awesome to simply be able to add a Meta
> property to a model to enable this functionality without having to inherit
> the Mixin.
>
> It would be an honor to be able to contribute to Django's core
> functionality after so many years of using the framework. I'm hopeful
> you'll consider my proposal.
>
> Kindest Regards,
> Brandon Taylor
>
> --
> 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/389733b0-cccf-4359-9cc7-
> 0d6883f9d495%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/CAMyDDM3TGJHBWQLeeZmxiDmR6EKPoYbTU7q0GS8RnLW4A5ctyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

2017-03-21 Thread Adam Johnson
It does seem like a somewhat arbitrary historical restriction. Collin's PoC
change is surprisingly small and simple.

Seems like it would be fine if Django allowed add() and let any errors
> about missing data bubble-up.
>

Agree, this is also a precedent from get_or_create.


> I personally think passing in a defaults dict (just like get_or_create
> does) would also be fine, but a callback seems like overkill.
>

This is a more consistent approach to the callback. One could always use
custom logic in the through model's save method, or a signal, to achieve
things that can't be done with through_defaults.

On 21 March 2017 at 00:46, Collin Anderson  wrote:

> Hi,
>
> Check out https://code.djangoproject.com/ticket/9475
>
> Seems like it would be fine if Django allowed add() and let any errors
> about missing data bubble-up. I personally think passing in a defaults dict
> (just like get_or_create does) would also be fine, but a callback seems
> like overkill.
>
> Here's a proof of concept: https://github.com/
> django/django/compare/master...collinanderson:ticket9475
>
> Collin
>
>
> On Mon, Mar 20, 2017 at 5:46 PM, Luis Masuelli 
> wrote:
>
>> I was reading this link in the official history
>>  and this other
>> link in this group
>> ,
>> but still do not understand why the issue against a way to call .add() to
>> add a through model. I thought several approaches (they are all backward
>> compatible for the end-user) that could work:
>>
>>1. Avoid the restriction to call add() if the model has only the two
>>FK fields.
>>2. An additional way to call .add() specifying additional fields to
>>fill (this one is not mine; was discussed in the linked thread). You risk
>>getting a (wrapped?) exception if you do not populate other fields
>>appropriately.
>>3. (This one was the first I thought and perhaps the easiest to
>>implement) Allow the ManyToManyField to specify a kwarg like
>>`through_factory=` which expects a callable which would populate more 
>> data.
>>The restriction to call .add() would remain if no `through_factory=` is
>>specified.
>>4. Avoid the restriction to call delete() if the model has only the
>>two FK fields.
>>
>> I considered these cases:
>>
>>- It is quite trivial a model with only two fields, but perhaps the
>>intermediate models could have additional useful methods. I see no trouble
>>having such model and allowing .add() or .delete() calls there.
>>- Having a special factory method would allow calls to .add() since
>>we'd be providing a way to make .add() actually know how to create an
>>instance of the intermediate model.
>>- You can combine these points, implement one, none, or all of them.
>>- (I did not consider extended use cases for delete() intentionally,
>>since perhaps a strange model (with different field pairs) could fit in
>>different relationships, although I cannot think in a case with multiple
>>relationships not incurrin in, perhaps, duplicate data when tried to be
>>used as through= model, but anyway I prefer to keep silence for other 
>> cases
>>involving delete(), but the case I stated).
>>- It is up to the user to be careful regarding migrating an
>>intermediate model regarding adding, changing, or deleting fields. But
>>anyway, this applies to any modification in the database models right now.
>>- Points 1, 2, 3 and/or 4 could be implemented with no clash. A
>>combined approach of 1, 2, 3 would look like this (this flow only applies
>>for the case when the through= is present - such scenario right now only
>>consists of raising an exception; the case with no through= model would 
>> not
>>be affected at all):
>>   - Instantiate `instance = ThroughModel(fka=a, fkb=b,
>>   **kwargs_from_add)` with the respective model instances a and b, from
>>   classes A and B which hold the desired M2M relationship. In this case, 
>> the
>>   point 2 just adds the **kwargs_from_add. If point 2 is not 
>> implemented, no
>>   **kwargs_from_add would be present.
>>   - (*If point 3 is implemented*) Call the callable in
>>   `through_factory=` invoking it `like_this(instance)`, if the callable 
>> is
>>   present. It is expected to save the instance.
>>   - (*If either point 1 is implemented and the model has only two
>>   fields, or point 2 is implemented*) Manually save the instance (if
>>   point 3 was not implemented or it was but the factory callable was not
>>   specified). (*Otherwise - point 2 not implemented AND (point 1 not
>>   implemented or model with more than two fields*)) Raise the
>>   currently implemented exception for the .add() method with through=
>>   specified (with a different string message)