On Mon, 2017-02-27 at 21:03 -0800, Asif Saifuddin wrote: > Hi Julian, > > > I have been also reviewing and studying the previous works, deps, discussions, codes and tickets. I have also been working to prepare a new dep based on the previous works. >
I haven't had a chance to review Michael's code (is there a github link?) but I think the composite field approach is almost certainly a sensible route. Which is a shame because it adds quite a bit of extrope tha refactor work for me. ;-). The code I have got[2], does not take that route[1], shows the switch between single field and composite primary adds a lot of complexity to far too many (IMHO) code routes. If it was a handful I wouldn't worry a great deal, but there is a lot of complexities which fall on the admin code which don't quite fall out as neatly as I would like. Hence I hope that by providing a named composite field, then we mitigate the issues above as arguable we still only have single field PK, but that that field is itself composite which may well mitigate the issues I have been seeing. [1] We took a patch from somewhere which allowed multiple primary_key=True specifications in the model. [2] Initially developed by by one of by colleagues based on some other patches he found - We may unfortunately have lost the attribution. -- Roger Gammans <[email protected]> -- 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 [email protected]. To post to this group, send email to [email protected]. 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/1488267322.2524.18.camel%40gammascience.co.uk. For more options, visit https://groups.google.com/d/optout.
