Re: Composite Primary Keys

On Tue, Feb 16, 2016 at 05:38:12PM -0800, Cristiano Coelho wrote: > Hello there, > > What's the status for this? This > (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 years > old (last edit) and the links on it are even older. Googling around only > gave me some very old

Re: Composite Primary Keys

Sounds cool, I think we would totally use that. On Wednesday, February 17, 2016 at 1:55:15 AM UTC-8, Roger Gammans wrote: > > Hi, > > > We've got some patches that we are using in production, against > 1.8 . Out long term aim would be to get them ready for a PR , but I they > are missing all

Re: Composite Primary Keys

Hi, We've got some patches that we are using in production, against 1.8 . Out long term aim would be to get them ready for a PR , but I they are missing all sorts of things, such unit tests and migrations (we don't use migrations at the moment - long story, so these haven't been tested). The

Composite Primary Keys

Hello there, What's the status for this? This (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 years old (last edit) and the links on it are even older. Googling around only gave me some very old projects so it wasn't good neither. -- You received this message because you

Re: Composite primary keys

On Thu, Mar 31, 2011 at 09:54:49AM -0700, Christophe Pettus wrote: > What concerns me about composite fields is that they seem to be a > lot of Python machinery just to accomplish the goal of allowing this > annotation. If they were super-useful in their own right, that > would be one thing, but

Re: Composite primary keys

On Mar 21, 2011, at 12:20 PM, Jacob Kaplan-Moss wrote: > I think we're talking slightly different concerns here: I'm mostly > interested in the Python-side API, and to my eyes a composite field > matches more closely what's happening on the Python side of things. I agree 100%! I think I'm just

Re: Composite primary keys

e's a way we can merge these two things together somehow? The composite index could be achieved by the standard field option Field.db_index applied to a CompositeField. This would still be consistent with the rest of the API since it would not require any new construct to do this thing. To sum up, I believe the CompositeField could be a general solution to both composite primary keys and composite indexes. Michal Petrucha signature.asc Description: Digital signature

Re: Composite primary keys

On Mon, Mar 21, 2011 at 2:33 AM, Christophe Pettus wrote: > I'd like to make one more pitch for a slightly different implementation here. >  My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't

Re: Composite primary keys

On Mar 21, 1:20 pm, Michal Petrucha wrote: > > My suggestion is to create an Index type that can be included in a > > class just like a field can.  The example we've been using would > > then look like: > > > class Foo(Model): > >    x = models.FloatField() > >    y =

Re: Composite primary keys

e following code would work for composite primary keys the same way it works for simple keys: class CompositeModel(models.Model): a = models.IntegerField() b = models.IntegerField() key = models.CompositeField((a, b), primary_key=True) class ReferencingModel(models.Model): cm = model

Re: Composite primary keys

Am 21.03.2011 um 08:33 schrieb Christophe Pettus: > I'd like to make one more pitch for a slightly different implementation here. > My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't have any of the >

Re: Composite primary keys

I'd like to make one more pitch for a slightly different implementation here. My concern with CompositeField isn't based on the fact that it doesn't map one-to-one with a field in the table; it's that it doesn't have any of the semantics that are associated with a field. In particular, it

Re: Composite primary keys

On Thu, Mar 17, 2011 at 09:33:43AM -0500, Jacob Kaplan-Moss wrote: > On Wed, Mar 16, 2011 at 4:24 AM, Johannes Dollinger > <emulb...@googlemail.com> wrote: > > I would be nice if support for composite primary keys would be > > implemented as a special case of

Re: Composite primary keys

On 17 March 2011 16:18, Mike Axiak wrote: > Just to be clear, for this to be valid syntax doesn't this idea have to be > written as:: >    class Foo(Model): >       x = models.FloatField() >       y = models.FloatField() >       coords = models.CompositeField(('x', 'y'),

Re: Composite primary keys

Just to be clear, for this to be valid syntax doesn't this idea have to be written as:: class Foo(Model): x = models.FloatField() y = models.FloatField() coords = models.CompositeField(('x', 'y'), db_index=True) a = models.ForeignKey(A) b = models.ForeignKey(B)

Re: Composite primary keys

On Wed, Mar 16, 2011 at 4:24 AM, Johannes Dollinger <emulb...@googlemail.com> wrote: > I would be nice if support for composite primary keys would be implemented as > a special case of general composite fields. There would be no need for new > Meta options: > > cla

Re: Composite primary keys

=True be a shortcut to creating one. That might be more machinery than we want just for composite primary keys though. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to thi

Re: Composite primary keys

On Mar 16, 11:43 am, Christophe Pettus <x...@thebuild.com> wrote: > On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote: > > > I would be nice if support for composite primary keys would be implemented > > as a special case of general composite fields. > > I

Re: Composite primary keys

On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote: > I would be nice if support for composite primary keys would be implemented as > a special case of general composite fields. It's appealing, but the reality is that no existing back-end actually has such an animal as a composite

Re: Composite primary keys

I would be nice if support for composite primary keys would be implemented as a special case of general composite fields. There would be no need for new Meta options: class Foo(Model): x = models.FloatField() y = models.FloatField() coords = models.CompositeField((x, y), db_index

Re: Composite primary keys

On Wed, 16 Mar 2011 07:49:17 +0200, Michal Petrucha wrote: On Tue, Mar 15, 2011 at 09:15:29PM -0500, Javier Guerra Giraldez wrote: On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus wrote: > A concern here is that composite indexes, like unique,

Re: Composite primary keys

On Tue, Mar 15, 2011 at 09:15:29PM -0500, Javier Guerra Giraldez wrote: > On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus wrote: > > A concern here is that composite indexes, like unique, are > > sensitive to the ordering of the fields, which means that the > > ordering of

Re: Composite primary keys

On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus wrote: > A concern here is that composite indexes, like unique, are sensitive to the > ordering of the fields, which means that the ordering of the fields in the > class declaration becomes important. a simplistic proposal:

Re: Composite primary keys

On Mar 15, 2011, at 5:06 PM, Russell Keith-Magee wrote: > And if you mark > multiple fields, then you have a composite primary key composed of > those fields. A concern here is that composite indexes, like unique, are sensitive to the ordering of the fields, which means that the ordering of

Re: Composite primary keys

On Tue, Mar 15, 2011 at 11:11 PM, Andrew Godwin wrote: > 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,

Re: Composite primary keys

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

Composite primary keys

not be the best idea: http://groups.google.com/group/django-developers/msg/dea0e360c6cd37a6 - 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

Re: Composite Primary Keys

Well GenericRelation's or whatever are an attempt to provide some composite space, but we need an expandable space, not something tied to content type's. We need to say mykey = CompositeField(field, field, field) or something. No one wanted to discuss it at DjangoCon, so no. On Thu, Oct 30, 2008

Re: Composite Primary Keys

That would be great. The project I am working on now won't be doing anything too terribly complex just yet; I mainly need the admin support to make my life a little easier. As to the API, I saw several proposals earlier along on this thread, but obviously nothing solid. Did anything ever come

Re: Composite Primary Keys

It allows you to use them, automatically creates them, and has some of the admin handling done. However, there's still no API design around multi-column fields (no one seems to want to talk about it) so I'm pretty much stopped working on it. e.g. You can't say field1 = this, field2 = that, and

Re: Composite Primary Keys

David, What is the current status of this patch? I'm starting up a new project which pretty much desperately needs this support as well. I could work around it, but the thought of adding AutoFields to all of these models which really -do not- need them, makes me a bit ill. I would be more than

Re: Composite Primary Keys

What we hope to achieve here is full support within the Django core, as opposed to specifying some kind of model. The only thing I have left to do is implement composite fields, but there's still no API for it. On Sat, Oct 4, 2008 at 12:03 PM, Eric <[EMAIL PROTECTED]> wrote: > > Hi, > i just

Re: Composite Primary Keys

Hi, i just discover this thread, I am working on this problem; you may take a look at http://kenai.com/projects/django-trac/pages/LegacyModule legacy is a module in my "django hacks trac" (or djac) project; it aims to deal with tables with no primary key or with composite pk. It provides 2

Re: Composite Primary Keys

On Wed, 2008-09-03 at 23:22 -0700, David Cramer wrote: > This is one of those things that I really need to get hammered out > (for our platform). I'm willing to do all the work, but I need a > design around it to where the patch won't get rejected :) No question. And for that, we have this very

Re: Composite Primary Keys

This is one of those things that I really need to get hammered out (for our platform). I'm willing to do all the work, but I need a design around it to where the patch won't get rejected :) On Sep 3, 11:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-02 at 22:02 -0700,

Re: Composite Primary Keys

For anyone who's interested, it'd be great to meetup at DjangoCon to go over a good design approach to composite fields. On Sep 2, 2:44 pm, Rock <[EMAIL PROTECTED]> wrote: > One use case for Composite Primary Keys is for setting up database > partitions. In my case I am usin

Re: Composite Primary Keys

On Tue, 2008-09-02 at 22:02 -0700, David Cramer wrote: > For anyone who's interested, it'd be great to meetup at DjangoCon to > go over a good design approach to composite fields. Take notes. There's going to be a lot going on at DjangoCon (including celebrating), so there will be a group who

Re: Composite Primary Keys

One use case for Composite Primary Keys is for setting up database partitions. In my case I am using Range-Hash partitions with the range determined by an IntegerField called "ISOweek" and the hash working off of the "id" field supplied by Django. To allow this partitioning

Re: Composite Primary Keys

I'm not quite sure how that relates to Composite Primary Keys? A ForeignKey would point to multiple internal fields, but it should look like it's a single field. At the same time, this would open up the possibility for Composite Foreign Keys, which would mean it could point to multiple public

Re: Composite Primary Keys

To be clear, the syntax is: myfkey = models.ForeignKey(SomeClass,to_field="id") --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Composite Primary Keys

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

Re: Composite Primary Keys

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

Re: Composite Primary Keys

What I had briefly discussed with malcom was using ordered tuples but switching up the defaults to use actualy field lookups. MyModel.objects.get(pk=(1, 2)) or MyModel.objects.get(foo=1, bar=2) If we could come up with some design for multi-column fields I'm wiling to put in the work. On Wed,

Re: Composite Primary Keys

El 28/08/2008, a las 0:27, David Cramer escribió: > 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

Re: Composite Primary Keys

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

Re: Composite Primary Keys

Any progress on this patch David? I would be happy to take a look at whatever you have and perhaps help out with completing the patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Composite Primary Keys

On Thu, May 8, 2008 at 7:57 PM, David Cramer <[EMAIL PROTECTED]> wrote: > I swear I saw something about work being done on this. Has anyone > begun? If not I'll gladly throw up a patch to get it into trunk. Please do. If you make sure it solves all three problems I outlined in #373

Re: Composite Primary Keys

On Fri, May 9, 2008 at 8:57 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > I swear I saw something about work being done on this. Has anyone > begun? If not I'll gladly throw up a patch to get it into trunk. The topic comes up fairly regularly, but I'm not aware of anyone that is actively

Composite Primary Keys

I swear I saw something about work being done on this. Has anyone begun? If not I'll gladly throw up a patch to get it into trunk. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to