Hello everyone, Hopefully some of you still remember me as the guy who's been trying to implement support for composite primary keys by means of composite model fields.
I haven't provided a whole lot of information on the progress of this project for... quite a long time, so I'll try to rectify this now and explain the current standing. A quick summary of GSoC 2011: I started by implementing CompositeField, which only acts as a dumb container. The obvious problem was that it wouldn't work with relationship fields, but other than that, it works just fine. Most importantly, using it as a primary key should work just fine. As far as relationship fields go, we tried to ignore them at first and get back to them during the second half of GSoC. Two approaches were considered, one was to special-case CompositeField targets in ForeignKey and in this case, make a single ForeignKey field manage multiple database columns directly. This turned out to be really painful and messy, so we tried another path, which was to turn ForeignKey into a virtual field and create an auxiliary copy of the target field in the local model which is supposed to manage the database column and its raw value. This way, ForeignKey only takes care of the higher-level relationship stuff. A large part of the ForeignKey refactor has been done. However, I was doing it on top of the CompositeField patchset, which makes it a real PITA to keep it in sync with master. I had managed to keep it in sync for about a year but this has become increasingly tedious, especially with all the Py3k changes and recent ORM improvements and cleanups. Currently my code is rebased on top of a commit from 2012-11-04, which is already five months in the past. It might be the case that it's simply because of me abusing git in a wrong way, but I've been keeping my work as a patchset on top of master using git rebase -- it helps me keep track of the progress I did and it is easier for me to find the commit where I did a certain change and why I did it in case I'm not sure what to do when a merge conflict appears. (If anyone is willing to teach me a better workflow, I'd be more than happy to take advice from more experienced users.) The more I think about it, the less I am convinced that trying to keep my patchsets in sync with master is worth the effort. When I implemented CompositeField itself, not having a clear idea of how ForeignKey would be brought into the equation and what kinds of abstraction would be required later, I implemented multiple things (like database creation or SQL WHERE statements) in a way that worked at that time, but require a more general handling with the abstractions introduced in the ForeignKey refactor. This basically means that I first implemented CompositeField and later broke most of its internal handling within the ORM (which is one of the reasons why keeping this in sync with master is difficult). The course of action I'd suggest at this moment is to first port the ForeignKey refactor on top of current master and make sure everything is perfectly backwards compatible. This would also create all the internal abstractions required to implement CompositeField, which means porting CompositeField on top of the ForeignKey refactor will be easier (at the very least, it will require less internal changes). As the past few years have shown, this project is far too time-consuming for an individual to make any significant progress just working on it in one's free time. Therefore I'm proposing to do this as part of the upcoming GSoC. That would mean I'd be working on it full-time for three months which should be enough to finally push this over the edge and at least finish this code-wise (and documentation-wise, of course), hopefully even get the revision history into a state where it'd be ready for review and eventually inclusion into master. If there are no serious objections to the proposed plan, in a couple of days I'll start working on a timeline for the GSoC project and I'll also write down the few more serious implementation issues I still don't really know how to approach. Have a great weekend everyone. Michal
signature.asc
Description: Digital signature
