Ha! It turns out that a to_field option already exists for ForeignKey. (I did not know that yesterday.) I have just verified that to_field(SomeClass,"id") works fine even if the PRIMARY KEY uses multiple columns. However, and this is the key point, the id field has to be marked as UNIQUE.
To prove all of this I have created a sqlresetpartition and resetpartition command that looks for classes to partition within your settings. It sets up the required multi-column primary key, marks the ID field as UNIQUE, and also does the other magic to create partitioned tables. (It also creates partitioned indexes as required.) This only works for Oracle and the solution is special cased for my needs, but it points the way forward. I will look over the partitioning logic for MySQL when I get a chance. Maybe by Django 1.5 or so we can include direct support for partitioned models. BTW, once I have the models properly created with partitions, none of my other django code requires any changes at all. Besides improved performance, I must say that it is a thrill to delete hundreds of thousands of old rows in less than a second. This is the key feature I needed for my django app. On Aug 27, 6:27 pm, Rock <[EMAIL PROTECTED]> wrote: > Well for one thing, if one of the columns happens to be named "ID", we > should use that for the relatedfields lookup column and that is that. > (BTW, does your approach allow the Django supplied ID field to be > combined with some other field(s) to make a multi-column key? This > would be bang up for future partitioning support.) > > Next I would suggest adding a meta model column designation like > "id_field" to specify a field to use for related classes. This might > be a good "80/20" solution that could serve for an initial test > version. > > On Aug 27, 5:27 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > > > > > Really I'm stuck at an architectural point. > > > I have database validation and synchronization done, and the admin is > > working. > > > What is left is more or less handling relatedfield lookups. The issue is, > > that field's are designed to reference more than one field, so it's a tough > > design deicision to make on how that should be approached.- Hide quoted > > text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
