Re: [GSoC] Composite fields once again

This sounds exciting. I can't wait for this to land in master. Thanks, Michal! On Sunday, June 2, 2013 10:22:36 AM UTC-4, Michal Petrucha wrote: > > Hello everyone, > > I'm happy to announce that throughout the summer I'll be officially > working on composite fields under the supervision of

Re: [GSoC] Composite fields -- another status report

Hello everyone, a lot of time has passed since I last posted a status report here and I apologize for that. Composite ForeignKeys were a fairly simple thing to implement with all the required parts already in place. There is one edge case that I'd like to handle, where Django would detect

[GSoC] Composite fields -- irregular status report #4

Hello, Last week I finished an implementation of CompositeField with support for backend-dependent IN lookups. During the past few days I also added support for composite primary keys to the admin. The latest work is available in the soc2013/composite-fields branch [1]. As a reminder, the

Re: [GSoC] Composite fields once again -- irregular status report #2

Hello, I apologize for the lack of updates on the progress of my project in the past few weeks, there just wasn't much to report, unfortunately. I spent the past two weeks porting the ForeignKey refactor on top of master. It took significantly more time to do than I anticipated due to all the

[GSoC] Composite fields -- weekly status report no. 1

Hello, The official coding period has started a week ago, therefore I guess a progress report is in order. As far as changes to the proposal are concerned, it seems there aren't any. There haven't been any objections or other suggestions to improve the proposal, other than the updatable primary

Re: [GSoC] Composite fields once again

On Jun 2, 2013, at 8:22 AM, Michal Petrucha wrote: > GenericForeignKey and nontrivial field types > > > As I've indicated in my proposal, just casting any value to a string > and then performing a reversible transformation on

Re: [GSoC composite fields] Late post-GSoC check-in #1

First off, let me apologize for not reporting progress after the SoC has ended. At first I thought I'd relax for a few days, but then the work started piling up and I think anyone can guess how it went from that point on... So, again, my apologies. Second, I want to say a big thank you to the

Re: [GSoC composite fields] Weekly check-in #1

Short summary of last week: The first challenge was to make auxiliary field creation work with ForeignKey targets. The first attempt was to move parts of the model preparation mechanics to AppCache. This turned out to be a dead end because when AppCache is being populated, while importing models

[GSoC composite fields] Weekly check-in #12 (Eh, is it that late already?)

My first attempt at auxiliary field creation ended up worse than expected, it turned out I had to iron out a few other issues, like concrete model inheritance. Anyway, I also encountered a problem with ForeignKeys whose target field is also a ForeignKey. The latter has to be set up first in this

Re: [GSoC composite fields] Weekly check-in #1

The last week I've been looking into related fields and all that stuff. As it turns out, the issue is much more complex than I originally anticipated and at the moment I have some doubts whether this can be achieved as part of this GSoC. Basically, there are two approaches to the task: 1) Make

[GSoC composite fields] Weekly check-in #7

Basic support in the admin is now working: adding, editing and deleting single instances with composite primary keys. Obviously, there's no inline support yet since relationship fields are not yet ready. Michal [1] https://github.com/konk/django signature.asc Description: Digital signature

[GSoC composite fields] Weekly check-in #6

Hi folks, Sorry about this delayed post. My repo now supports using CompositeField as a model's primary key, as far as models are concerned, that means, Model.pk and friends. For the next week, expect admin to work. THe work is underway, nothing worthy of publishing just yet. Michal [1]

Re: [GSoC composite fields] Weekly check-in (this should be #5, right...?)

Hi, some visible progress on my project at long last. I spent most of the last week digging deep inside the ORM's entrails to make composite field lookups possible and finally it looks promising. While working on this I found out the extra_filters approach I intended to use was a dead end (which

[GSoC composite fields] Another weekly check-in

Another weekly update. First off, I'd like to apologize for not posting one last week; I've been completely buried under exams and other school-related stuff during the past three weeks... Things have settled now at last so I'm back at my SoC and cathing up. My repo [1] now contains support for

Re: [GSoC composite fields] Weekly check-in #1

All right, time for another check-in. This isn't a lengthy one -- unfortunately last Tuesday my laptop failed me, leaving me with no replacement, which means I have to wait for it to return from the service center to be fully up and running. In the meantime, I managed to borrow an old one a

[GSoC composite fields] Weekly check-in #2

Hello again, time for the second weekly check-in. I apologize for not having posted the API as I promised yet, there's a lot of things going on in school. However, I started working on a ticket [1] as we're supposed to for the interim period. Not much else to report, hopefully the next week's

[GSoC composite fields] Weekly check-in #1

Hello everyone, I hope the introductions aren't necessary since I've already introduced myself in the past [1]. Just a recap, I'll be working, under the guidance of Jacob Kaplan-Moss, on support for composite model fields which will allow users to define models with composite primary keys. The

Re: [GSoC] Composite fields: proposal draft 2

I tried to incorporate the remarks into my proposal and I'm posting the updated parts. As usual, the full version is still available at http://people.ksp.sk/~johnny64/GSoC-full-proposal Retrieval and assignment Jacob has actually already provided a skeleton of the code

Re: [GSoC] Composite fields: proposal draft 1, full version

On Thu, Apr 07, 2011 at 03:36:52PM +0800, Russell Keith-Magee wrote: > On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha > wrote: > > GSoC 2011 Proposal: Composite Fields > > > > Hi Michal, > > This looks to be a fairly solid proposal.

Re: [GSoC] Composite fields: proposal, part 1

On Wed, Apr 06, 2011 at 04:57:39PM -0500, Jacob Kaplan-Moss wrote: > So far this looks pretty good to me. Assuming you get the rest done > with a similar level of detail I'll be voting to approve it (and > possibly signing up to mentor, time-willing). Thanks for the encouragement, I really

Re: [GSoC] Composite fields: proposal, part 1

On Thu, Apr 07, 2011 at 12:38:07AM +0200, Johannes Dollinger wrote: > The only downside is that you'll have to pick a name for the index – > even if you don't really care (that's historically been a problem > with `related_name`). But anyway, since Meta.unique_together > probably cannot be

Re: [GSoC] Composite fields: proposal draft 1, full version

On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha wrote: > GSoC 2011 Proposal: Composite Fields > Hi Michal, This looks to be a fairly solid proposal. You've done a lot of detailed research, and while I'm almost completely certain

Re: [GSoC] Composite fields: proposal, part 1

Am 06.04.2011 um 23:29 schrieb Michal Petrucha: > On Wed, Apr 06, 2011 at 06:22:33AM +0200, Johannes Dollinger wrote: >> >> Am 06.04.2011 um 02:45 schrieb Michal Petrucha: >> >> [snip] >> >>> unique and db_index >>> ~~~ >>> Implementing these will require some modifications in

Re: [GSoC] Composite fields: proposal, part 1

On Tue, Apr 5, 2011 at 7:45 PM, Michal Petrucha wrote: > Anyway, I'll post at least the part I have already written so that at > least something can be commented on for now. So far this looks pretty good to me. Assuming you get the rest done with a similar level of detail

Re: [GSoC] Composite fields: proposal, part 1

On Wed, Apr 06, 2011 at 06:22:33AM +0200, Johannes Dollinger wrote: > > Am 06.04.2011 um 02:45 schrieb Michal Petrucha: > > [snip] > > > unique and db_index > > ~~~ > > Implementing these will require some modifications in the backend code. > > The table creation code will have

Re: [GSoC] Composite fields: proposal draft 1, full version

> I started writing the draft for a full proposal, however, I don't have > time to finish it today as I have to revise for tomorrow's exam. I > will try to finish it in 12 hours at most since I know I'm already > posting it a little bit too late to make it possible to review it > thoroughly. Heh,

Re: [GSoC] Composite fields: proposal, part 1

Am 06.04.2011 um 02:45 schrieb Michal Petrucha: [snip] > unique and db_index > ~~~ > Implementing these will require some modifications in the backend code. > The table creation code will have to handle virtual fields as well as > local fields in the table creation and index

Re: [GSoC] Composite fields: proposal, part 1

I started writing the draft for a full proposal, however, I don't have time to finish it today as I have to revise for tomorrow's exam. I will try to finish it in 12 hours at most since I know I'm already posting it a little bit too late to make it possible to review it thoroughly. Anyway, I'll

Re: [GSoC] Composite fields

On Sun, Apr 03, 2011 at 03:08:51PM -0400, Alex Gaynor wrote: > Like Carl I haven't had time to properly read this, but one important thing > (IMO) to think about is not just having composite field support, but support > for "virtual" fields in general, that is fields that don't map to a database >

Re: [GSoC] Composite fields

On Sun, Apr 03, 2011 at 02:52:01PM -0400, Carl Meyer wrote: > I haven't had time yet to sit down and look at your implementation > questions for a CompositeField (how it works with lookups and Qs, etc), > but I do think that one design goal for a CompositeField implementation > is that we should

Re: [GSoC] Composite fields

On Sun, Apr 3, 2011 at 2:52 PM, Carl Meyer wrote: > Hi Michal, > > On 04/01/2011 09:22 PM, Michal Petrucha wrote: > > I propose to implement a CompositeField with the following properties: > > > > - will be represented as a namedtuple containing the values of the > > actual

Re: [GSoC] Composite fields

Hi Michal, On 04/01/2011 09:22 PM, Michal Petrucha wrote: > I propose to implement a CompositeField with the following properties: > > - will be represented as a namedtuple containing the values of the > actual fields it encapsulates > > - will support retrieval and assignment (assignment

[GSoC] Composite fields

After this thread: https://groups.google.com/d/topic/django-developers/Y0aAb792cTw/discussion I decided to modify my proposal a bit. (This, however, still doesn't even try to resemble a final proposal, I just need to get a few more things straight.) I propose to implement a CompositeField with