Another SoC Introduction
Ryan Bergstrom
My name is Ryan Bergstrom, and like the other SoC posts, I'm applying
to the Django team in this year's SoC. Like Jason, I thought I'd get
some feedback on my proposal before the deadlines start hitting, and
generally give an introduction to the community. So, the introduction:
21 years old, from Edmonton (the one up in Alberta, Canada, not that
evil copycat down in Kentucky that most weather services insist is the
only one). Been using Django for about 2 years, it looked interesting
and got me started in Python (a good thing if there ever was one).
Prior to that, my web apps were mostly written in PHP (needless to
say, I haven't looked back). Aside from Python, my main development
languages are C and LUA (since it's popular as a scripting language in
quite a few games). Currently in Computer Engineering at the
University of Alberta and, barring any major screwups, should be
getting my nice shiny piece of paper about a year from now.
Anyways, on to the actual ideas. Prior to the SoC stuff being released
this year, I had been working on a Django app that involved spitting
out statistics on sizeable amounts of data (maybe 250-300k rows at a
time). One of the fields was a DateTime that required microsecond
precision (which, of course, the standard SQL datetime fields don't
support, but a DateTime + Integer would). So, I was thinking it'd be
nice if Django could support aggregate queries and multi-column
fields. Lo and behold, both those ideas turn up on the ideas page.
Unfortunately, I noticed on the bugtracker that someone has already
done the aggregate query support (they posted their patch after the
SoC page was posted). So, I'd still like to do the multi-column field
support (and probably the static file handling in the dev server, but
I haven't fleshed that idea out completely yet).
I have a fairly decent idea about how to implement the guts of the
multi-column fields. I stuck together a quick idea of how the fields
could function at http://python.pastebin.com/m3fe1f8c9. To sum it up,
you can either specify a delimiter to be used and split up the raw
data, or, in certain cases (like integers), it can simply fill the
fields as it goes. I.e. for a 96 bit integer, it would put the lower
32 bits in field 1, the next 32 in field 2, and then the upper 32 in
field 3. My main question lies in the admin interface. I'm hesitant to
add support to the current admin for this, since it'd be a fair amount
of work (with validation and all) if the newforms-admin branch is
going to be merged into trunk any time soonish. Like, say, before the
end of the summer, for obvious reasons :)
Anyways, thanks for any input you can give, and I hope to be working
with some of you this summer,
Ryan Bergstrom
Russell Keith-Magee
>
Hi Ryan
> So, I'd still like to do the multi-column field
> support (and probably the static file handling in the dev server, but
> I haven't fleshed that idea out completely yet).
>
> I have a fairly decent idea about how to implement the guts of the
> multi-column fields.
Good idea, a useful contribution, and you're not the first person to
think of it:
http://code.djangoproject.com/ticket/5929
This has been accepted, but nobody is working on it to my knowledge. A
related concept is:
http://code.djangoproject.com/ticket/373
which extends the multi-column issue to primary keys. dcramer has
claimed this ticket, but I don't know how active he is working on it
(since is was claimed last September).
Some quick thoughts to get your mental juices flowing:
- There are two ways to think about multi-column in the tree: A single
field definition that rolls out as multiple database fields, and a
syntax for combining two model fields into a single logical field. The
latter approach is what is used by GenericRelations, but the former
would also be quite useful.
- If you address the primary key issue, the biggest issue is the
admin. Objects in the admin must be uniquely addressable, which means
that you need to work out how to split multiple primary keys in a URL.
This has been discussed a few times in the past on django-developers;
in short, there is no solution that is both simple and maintains 100%
correctness, but admin support is a prerequisite for any modifications
to primary keys.
- Don't bother doing anything with the current admin. Newforms Admin
might take a little while to get to completion, but even if it takes
longer than the end of the summer, nobody in the core is going to
spend any time trying to merge code into the trunk admin, only to need
to reinvent it in NFA.
Best of luck with your GSOC application.
Yours,
Russ Magee %-)
Ryan Bergstrom
I figured that was the case with the admin though, just wanted to
check, no point wasting time on something that's going to be replaced
soon.
Ryan
Malcolm Tredinnick
On Fri, 2008-03-21 at 11:59 +0900, Russell Keith-Magee wrote:
[...]
> - If you address the primary key issue, the biggest issue is the
> admin. Objects in the admin must be uniquely addressable, which means
> that you need to work out how to split multiple primary keys in a URL.
> This has been discussed a few times in the past on django-developers;
> in short, there is no solution that is both simple and maintains 100%
> correctness, but admin support is a prerequisite for any modifications
> to primary keys.
The bigger issue is probably best represented by generic relations. Both
this and admin logs are an example of things that are represented at one
end by (content type, object id) and we don't want to break every piece
of code in existence. As Jacob has pointed out at some point in the
past, the admin URL situation isn't too bad with respect to not breaking
backwards compat because the content type will enable us to determine if
it's a single column primary key or a multiple-column primary key.
I should say, though, that I suspect multi-column primary keys is
probably not a good summer of code project. Except for that one issue,
it's really fairly easy and that one issue is quite hard. So I don't see
there being a sustained 12 weeks of work in that. You'll either spend 10
weeks thinking about that one problem or be done in the first couple of
weeks.
Plus I kind of have to solve some of this multi-column stuff in the next
few days to get queryset-refactor finished. The last remaining big thing
is reverse generic relations and I want to create a proper solution
there, not a content-type-based hack that's specific to that one field.
Still a general infrastructure (the class outline) for creating a
multi-column field would be interesting to have, but, again, I'm not
sure it's a full summer's worth of coding.
Malcolm
--
Experience is something you don't get until just after you need it.
http://www.pointy-stick.com/blog/