Just my late 2 cents to this... First, I wouldn't put too much weight on the DEP proposals. Looking back to them now, I don't think they went to the right direction.
For Michal Petrucha's work, it was really close to being merged some years ago. The problem was that migrations happened at the same time, and that resulted in need of substantial changes to Michal's work, and unfortunately this never happened. So, I'd put a lot of weight on this work. If I'd were to take on this task, I'd try to develop the feature with the idea of merging the work in multiple batches. For example this might be a possible plan: 1. Introduce virtual/composite field, only CREATE TABLE migrations support at this point, not documented as public API 2. Add support for primary key and unique composite fields, again non-public 3. Work on foreign keys, again non-public 4. Migrations support 5. Make the work public API (that is, document the work) This would give a chance to get the work done in incremental pieces. Doing this all in one go is such a large task that there is a big risk of not getting this done at all. Whatever approach you take, I really hope you'll be able to work on this and get this long waited feature in to Django. - Anssi On Wednesday, March 1, 2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote: > > Hi Julien, > > I will publish it very soon. > > Thanks > > On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote: >> >> Hi Asif, >> >> That sounds good. On first look I did have some reservations about some >> of the design details in the current DEP, especially around the observer >> pattern for data binding. But I’m going to have to dig deeper into the >> implementation to get a clearer idea. >> >> It’d be great if you could publish your work-in-progress at some point so >> we can discuss the approach in more detail. >> >> Thanks, >> >> Julien >> >> On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin <auv...@gmail.com> 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. >>> >>> Like what Michal said, from my observation, I found the works and >>> approaches of Michal is quite better and it's possible to break the work >>> down into smaller parts to implement gradually. >>> >>> I am not quite sure how much work or which approaches of Thomas >>> Stephenson in 2015 could be mixed or needed with Michal's approach. In my >>> humble opinion Michal spent more time in working on this and I also found >>> his insights and suggestions on this topic more sensible. >>> >>> I would also like to work on this. My Dep is not yet ready for a push. >>> >>> You could certainly review and give you input on the Dep. Some core >>> members suggested me to finalize a Dep before div into code. >>> >>> Let me know what your thoughts. >>> >>> Regards, >>> >>> Asif >>> >>> I have also contact with >>> >>> On Tuesday, November 29, 2016 at 6:10:38 PM UTC+6, Craig Kerstiens wrote: >>>> >>>> Hi all, >>>> >>>> My company (Citus Data) is interested in sponsoring some Django work. >>>> In particular work on support for composite primary keys. From what I >>>> understand this wouldn't be the first time the work has been explored and >>>> it sounds like it has a number of intricacies to it ( >>>> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst >>>> and >>>> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst). >>>> >>>> Our hope here is that it would be done in line with something that could >>>> eventually become part of an official Django release vs. a one-off work >>>> around. >>>> >>>> While we know there's no guarantee of it being accepted, we'd love to >>>> find someone with some knowledge of all the existing areas that would have >>>> to be touched and has some experience contributing to Django core to >>>> improve that likelihood. As part of the work, we would want the two >>>> existing DEPs to be completed and work towards getting those accepted by >>>> the broader community. And hopefully it goes without saying, but we'd >>>> fully >>>> expect all the work to done in the open similar to other Django >>>> development. >>>> >>>> If you're interested in doing this work please reach out as we'd love >>>> to discuss further. And if we have enough interest we'll be doing a full >>>> CFP for the work to try to keep the process as fair as possible. >>>> >>>> ~ Craig >>>> >>>> -- >>> 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/cc29383b-b930-4d4c-9f48-51fa10909ecd%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/cc29383b-b930-4d4c-9f48-51fa10909ecd%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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 email@example.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/dae2ef67-99cf-4782-96fb-a399a3bb6ae3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.