On 14/03/11 21:14, Michal Petrucha wrote:
Good evening (or whatever it is in everyone's timezone).
I'm an undergrad computer science student at the Faculty of
Mathematics, Physics and Informatics, Commenius University,
Bratislava, Slovakia and I'm willing to participate in this year's
GSoc. I'm interested in fixing the six-year-old open ticket in trac
concerning the subject, http://code.djangoproject.com/ticket/373
Firstly, thanks for proposing a GSoC project - it's always nice to have
more students. Bear in mind that the list of accepted organisations
hasn't been published yet, but we're pretty hopeful Django will make it
in again this year.
Before I dig deeper into the issue I would like to know whether there
is interest in having this fixed and whether it is worth a full GSoC
project. Also, is there already any work regarding this issue
underway? If so, would it be reasonable for me to go on with this
project?
Anyway, if I'm to take on the task, there are quite a few design
considerations to be taken care of.
For starters, I've read through David Cramer's work on this from
two-three years ago. I'd stick to the API skeleton that was agreed on
back then, however, there remain lots of other unresolved questions.
The following list is in no way meant to be exhaustive, it's just a
list of things that came to my mind during the past hour. In fact, I'd
appreciate other issues that would need to be kept in mind I forgot to
mention.
- The composite primary key would be specified as a tuple of strings
in a primary_key attribute inside a model's Meta class instead of
having a field with primary_key=True.
That seems to match with our current handling of things like unique, so
that seems fairly reasonable.
- The pk property of model instances would be a tuple instead of a
single value for composite key models.
So the property will vary type based on the model? Obviously this is
needed for backwards-compatability, but it's still going to affect e.g.
library authors, so we'd need to make sure everything that previously
accepted a PK also accepts a tuple.
- The admin could reference composite keys using some kind of smart
string escaping, for example escaping the , (comma) and using it as
a delimiter.
That should work, though it might be a bit ugly; again, I can't think of
a better alternative.
- This could maybe even be used in generic relations. Is it
reasonable to support this in generic relations? The following post
suggests it might not be the best idea:
http://groups.google.com/group/django-developers/msg/dea0e360c6cd37a6
Generic relations are ugly and inefficient as it is; I'm not sure that
including them in something like this is strictly necessary, much as
Malcolm suggests, and probably outside the scope of a GSoC project
(something of this scale is already touching a lot of places in the
model layer as it is)
- The managers and querysets would have to be updated to handle
composite primary keys correctly.
- Consequently, there would need to be added support in the SQL
compiler.
- The same holds for syncdb, inspectdb would be also nice.
I'd say inspectdb isn't strictly necessary - not very many people use
it. I'll also be looking at potentally merging in some schema alteration
code (i.e. moving parts of the South database backends) over the next
few months, so it's going to affect that, too, though I'm more than
happy to help fix that part (the existing creation code will definitely
need changing, at least).
- ForeignKeys would have to be backed by multiple database columns.
How should they be named by default? How should their names be
overriden? Should db_column expect a tuple of strings? Should there
be another db_column_prefix option to prefix the names with a
common string?
These are some very good questions, and something we need a good
discussion here about; I'd personally say doing "fkname_remotecolname"
is best for the columns (which then means "author_id" still matches most
DBs, and you could also have something like "passport_country_id,
passport_number").
I'm also -0 on the idea of a db_column_prefix, but db_column is going to
need to take tuples/sequences for multi-column FKs.
- What about the ForeignKey field's attname? Should it be a tuple of
names or should it be a single string pointing to a tuple of
attributes?
I'd say a single string pointing to a tuple - I don't like fields which
'magically' make more attributes than the name they were assigned. That
also makes sense if you think of the foreign key as a single entity
composed of several values.
- How should a person trying to add a ForeignKey field pointing to
its own model into the primary_key be punished?
Preferably with a model validation error.
- Does it make sense to make a subset of columns created by a
ForeignKey part of a primary key?
Provided they're then mixed in with at least one other column, yes.
However, I'm not sure this is strictly necessary for us to cover.
- The forms framework would need a way to pass composite ForeignKeys
as parameters.
Yes, that's going to be interesting. I'd love to see a more concrete
example of a proposed API here, though I expect it to involve tuples,
and some form of escaping for returning the values via POST.
- What about OneToOne?
OneToOne fields will need to have the same capabilities, though they
share nearly all their code with ForeignKeys. A related issue is going
to be making sure model inheritance works properly - that uses
OneToOneFields between non-abstract parents and their children.
Some items in this list are my ideas on how to implement something,
some are things already decided during previous attempts, others are
questions which I believe are not entirely up to me to decide on. I'll
be grateful for any comments on any of these points and as I said
earlier, any other considerations related to the topic.
Also, these would somehow have to be split into two parts: those
to be focused on from the perspective of this project and those to be
postponed to a later stage or with little relevance.
Yes; I'd say that there's plenty of work here for a GSoC project, so I'd
consider limiting the scope of a first phase to make sure things work
alright (there's a lot of work even without ForeignKeys and model
inheritance - you have to touch queries, creation, model forms, the
admin, and so on).
I'd recommend taking a good look through the model layer code if you
haven't already and getting an idea of what sort of changes need to be
made; this kind of feature is going to be heavy on integration and
changes to pretty core code, so we'd want to make sure you kept
up-to-date with trunk reasonably well as well, otherwise it can be easy
to end up with an unmergeable branch.
Finally, a warning that to attempt this you'll need to have a decent
knowledge of SQL, the various database backends, and at least the usage
of the Django model layer - this is an area where several have tried and
not got very far, so it takes a little bit of determination and a
willingness to delve into some of the more complex parts of Django's
codebase.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
