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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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.
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
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
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
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
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
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
> 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,
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
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
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
>
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
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
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
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
33 matches
Mail list logo