Hi everyone, I can't speak for Thomas' implementation, as I haven't had the time and energy to look into it too much, but I can try to clarify some aspects of what I did years ago.
On Mon, Feb 27, 2017 at 11:10:55AM -0800, Julien Phalip wrote: > Composite primary keys (GSoC) > > ========================= > > > Michal Petrucha participated in two Google Summer of Code (GSoC) projects > in 2011 and 2013, during which some extensive code, tests and documentation > were written. Unfortunately this project didn't reach the point where it > could be merged into core and it eventually fell behind. Some relevant > resources about these projects can be found here: > > - GSoC'2013 proposal: https://gist.github.com/koniiiik/5408673 > > - GSoC'2013 status updates: > https://groups.google.com/forum/#!topic/django-developers/CD7OrkJ63zc > > - Discussion about some implementation details: > https://github.com/django/django/pull/1407 > > - Status update from Michal from last year: > https://groups.google.com/forum/#!topic/django-developers/SunyXc_BTVM > > > Michal's implementation work is divided in two separate branches > ("composite-fields" and "foreignkey-refactor"), presented below with their > corresponding list of commits: > > > "composite-fields" branch: > > - Branch: https://github.com/koniiiik/django/tree/soc2013/composite-fields > > - Commits: > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d63cde8891d...koniiiik:soc2013/composite-fields > > > "foreign-refactor" branch: > > - Branch: > https://github.com/koniiiik/django/tree/soc2013/foreignkey-refactor > > - Commits: > https://github.com/django/django/compare/041a076dadce547d450cf73d97401d63cde8891d...koniiiik:soc2013/foreignkey-refactor > > > I took a quick stab at merging current master into those branches but > didn't make it too far as it turned out to be a little tedious. The main > reason is that since 2013 there have been extensive changes in the ORM > internals, in particular around the Meta api. So I'm not sure if it's worth > doing that merge at this point. However, it'd be a shame to let all that > great work go to waste and hopefully some of it can still be reused. Sadly, I don't see how a merge of current master would be feasible with those branches. This all happened before migrations, the explicit AppRegistry, and all the meta changes were merged, all of which cause quite some conflicts. It should be feasible to port significant portions of my old work onto master, though, commit by commit. > Some questions: > > - Are there any portions of code or some solutions from Michal's > implementation that could be ported over to the DEPs and to Thomas' more > recent implementation? I would hope so, but unfortunately, can't say with any certainty. Even if I just look at the interface, Thomas' approach seems quite different from mine, but without going through the code, it's hard for me to tell what parts could be relevant. > - What is the difference or relationship between the "composite-fields" and > "foreignkey-refactor" branches? Right, so the gist of it is that if we ever want to support composite foreign keys, it will be necessary to turn ForeignKey into a virtual field, which is exactly what I attempted to achieve in the “foreignkey-refactor” branch. This would also have the neat side effect of clearly defining what even is a virtual field in the ORM, since that was definitely not a very well defined concept at the time. (I think it's gotten better with the formalization of _meta, but it's still very heavily influenced by the early approach of “any aspects of GenericForeignKey that don't closely match regular fields”.) My thinking was that I'd first try to get the refactoring part as solid as possible, and only then start to build on that by introducing the new concept of composite fields. Unfortunately, I seem to have crammed too much into the GSoC project, so I couldn't really stop and take the time to get the FK refactor over the finish line, and instead focused on getting as much of the new-feature code finished as possible. So yeah, foreignkey-refactor is the part where I turned ForeignKey into a virtual field, and composite-fields is the part based on the first branch where I added composite fields to the equation. FWIW, there's https://code.djangoproject.com/ticket/16508 where I've tried to introduce some prerequisites for the ForeignKey refactor in smaller chunks. > - Should a new DEP be submitted to specifically tackle composite primary > keys and foreign keys? Good question. At a glance, Thomas' DEPs do not mention composite foreign keys at all, so I guess if we want support for those at some point, the complexity of this task would definitely warrant a DEP. Anyway, most of this email focuses on virtual FKs, rather than composite fields and composite primary keys. In my mind, that's the order in which those things make sense, but I may be overly ambitious here (and history seems to agree with that sentiment). Cheers, Michal -- 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/20170227204442.GY23772%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
