Re: Proposal: Composite Foreign Keys

I thought there were several patches or workarounds proposed in the thread that I commented on. I did not mean to kick a hornets nest. I'll just back away quietly now and see if I can switch everything over to SQLAlchemy like one of the other comments suggested. On Thu, Nov 29, 2012 at 5:02 PM,

Re: Proposal: Composite Foreign Keys

I'm sorry, I did not indent for it to be hostile or rude but, after reading it I guess it could sound that way. I was more frustrated because I was sure I was missing something somewhere. On Thu, Nov 29, 2012 at 5:06 PM, Jacob Kaplan-Moss wrote: > On Thu, Nov 29, 2012 at 4:43

Re: Proposal: Composite Foreign Keys

On Thu, Nov 29, 2012 at 4:43 PM, Ron Smith wrote: > So here we are 4 years later, version 1.5 is about to be released and we > still don't have a solution for composite primary keys in the code base? Or > am I missing it in the docs somewhere? I'm not sure if you meant to,

Re: Proposal: Composite Foreign Keys

No, there is no such solution in the codebase. Are you aware of a patch we should be reviewing on this issue? Alex On Thu, Nov 29, 2012 at 2:43 PM, Ron Smith wrote: > So here we are 4 years later, version 1.5 is about to be released and we > still don't have a solution

Re: Proposal: Composite Foreign Keys

So here we are 4 years later, version 1.5 is about to be released and we still don't have a solution for composite primary keys in the code base? Or am I missing it in the docs somewhere? -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: Proposal: Composite Foreign Keys

On Wed, Nov 19, 2008 at 19:12, David Cramer <[EMAIL PROTECTED]> wrote: > You guys are really bad about keeping on topic. :) Good way to prevent a discussion from entering Godwin-territory :) I should perhaps have mentioned something along the lines of "this is an example of where there is

Re: Proposal: Composite Foreign Keys

You guys are really bad about keeping on topic. :) On Wed, Nov 19, 2008 at 9:32 AM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > Hanne, > > I ran into that exact problem myself and filed the following ticket related > to the issue: http://code.djangoproject.com/ticket/9519 > > I also found that you

Re: Proposal: Composite Foreign Keys

Hanne, I ran into that exact problem myself and filed the following ticket related to the issue: http://code.djangoproject.com/ticket/9519 I also found that you could run your own delete operation through the ORM, however, to work around this. It's more work and certainly not in line with DRY or

Re: Proposal: Composite Foreign Keys

On Mon, Nov 17, 2008 at 00:55, Frank Liu <[EMAIL PROTECTED]> wrote: > Plus, if you had a chance to look at the type of databases that I have > to deal with by day, you will see why this is so important to me. Yo. Not that big, but there's a DBA involved for some of 'em. Let's just say I can't

Re: Proposal: Composite Foreign Keys

What is the big deal? I was on a gig recently where Django was used with Oracle. To support model partitioning for selected models, we munged the generated SQL for model creation to add composite keys and the partitioning logic. It was a little bit hairy, but once the model creation was correct,

Re: Proposal: Composite Foreign Keys

On Sun, 2008-11-16 at 15:55 -0800, Frank Liu wrote: > Hi Jacob, > > Let me apologize first for using JKM as an alias to the whole core > team. I guess the problem here is that adding this feature really > entail changes in too many areas. It would be nice if you and the > other core team

Re: Proposal: Composite Foreign Keys

On Sun, Nov 16, 2008 at 5:50 PM, David Cramer <[EMAIL PROTECTED]> wrote: > http://github.com/dcramer/django-compositepks/tree/master# Cool; I'll take a look tomorrow. Do you want me to make changes in my own tree, or would you rather patches back to you? Jacob

Re: Proposal: Composite Foreign Keys

So far it allows declaration and creation of primary key models. You declare them in class Meta: primary_key = ('field', 'field', 'field'). There is no ForeignKey/Relational? handlers as of right now, but the admin is mostly working. Alex Gaynor pointed out there is one unrelated change I

Re: Proposal: Composite Foreign Keys

Hi Jacob, Let me apologize first for using JKM as an alias to the whole core team. I guess the problem here is that adding this feature really entail changes in too many areas. It would be nice if you and the other core team members can set a direction for changes on this issue. The various

Re: Proposal: Composite Foreign Keys

On Sun, Nov 16, 2008 at 5:19 PM, David Cramer <[EMAIL PROTECTED]> wrote: > Also keep in mind that work has been done, but as I haven't had a lot of > spare time to continue it (attempt #3?). It's a very complex problem as > well, like Jacob mentioned. You have to deal w/ the legacy use of single

Re: Proposal: Composite Foreign Keys

Also keep in mind that work has been done, but as I haven't had a lot of spare time to continue it (attempt #3?). It's a very complex problem as well, like Jacob mentioned. You have to deal w/ the legacy use of single primary keys, as well as the new composites. While I almost have a fully

Re: Proposal: Composite Foreign Keys

Hi Frank -- It's hard for me to figure out how to answer this: if you've got a problem with my leadership skills, I don't really see how anything I say makes much of a difference. Frankly, your tone is completely inappropriate and I feel I'm enforcing absurdly out-of-line behavior simply by

Re: Proposal: Composite Foreign Keys

I guess i thought the core developers would've added this proposal to the list (judging from the title of this thread). Regardless, even if this had been added, it would've been given a -1 anyway, judging from the readiness of this feature. More importantly though, my gripe about this is that

Re: Proposal: Composite Foreign Keys

On Sun, Nov 16, 2008 at 2:42 PM, Frank Liu <[EMAIL PROTECTED]> wrote: > > @#$%!.will this composite primary key feature be included in > Django 2.0? Or will this be ever included? Let me explain my > frustration a bit. > > [snipped] Did I miss something? Your note makes it sound like the

Re: Proposal: Composite Foreign Keys

@#$%!.will this composite primary key feature be included in Django 2.0? Or will this be ever included? Let me explain my frustration a bit. My company only allows Oracle db and the legacy tables span hundreds of schemas and hundreds of tables in each schema, in multiple databases. This

Re: Proposal: Composite Foreign Keys

Malcolm Tredinnick wrote: > On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: > [...] > >>> Maybe be you mean transparently. If so, I think this is a requirement, >>> too, but it's not a problem. We know when the ForeignKey field is >>> specified which model it refers to, so we can

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: [...] > > Maybe be you mean transparently. If so, I think this is a requirement, > > too, but it's not a problem. We know when the ForeignKey field is > > specified which model it refers to, so we can include the correct number > > of

Re: Proposal: Composite Foreign Keys

Malcolm Tredinnick wrote: > > On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: >> I was thinking beyond just handling Foreign Keys actually when I wrote >> this up. It would allow for a more generic version of a generic >> foreign key. > > Generic relations are quite different to foreign

Re: Proposal: Composite Foreign Keys

Ya this was more of a two birds one stone goal here. It'd be nice to be able to specify relations (e.g. the filter example), like it would with a generic foreign key, but not restricted to content_type/ object_id. We also will run into the issue with that, where object_id is a composite as well

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: > I was thinking beyond just handling Foreign Keys actually when I wrote > this up. It would allow for a more generic version of a generic > foreign key. Generic relations are quite different to foreign keys and the two shouldn't be merged.

Re: Proposal: Composite Foreign Keys

I was thinking beyond just handling Foreign Keys actually when I wrote this up. It would allow for a more generic version of a generic foreign key. Although the more I think about it we'd still want to magically handle ForeignKey's so the same problem exists. I guess I could write a composite

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 10:53 -0800, David Cramer wrote: > Here's my proposal for the composite keys (which act much like generic > keys except more useful): > > class MyModel2: > pass > > class MyModel3: > pk_part1 = models.AutoField() > pk_part2 = models.ForeignKey(MyModel2) >

Proposal: Composite Foreign Keys

Here's my proposal for the composite keys (which act much like generic keys except more useful): class MyModel2: pass class MyModel3: pk_part1 = models.AutoField() pk_part2 = models.ForeignKey(MyModel2) name = models.TextField() class MyModel: pk_part1 =