@#$%!.....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 limitation on single primary key and single databse connection single schema is really making me feel that Django is only catering to the simple bloggers and social networkers. However, to django's credit, Django is very well designed. But without having the aforementioned resolved, i will never be able to get my team to deploy django formally. It only leaves me with a sigh of not being able to use all of this great work but having to suffer through php (yes currently our legacy reporting tool is written in php, in >1000 lines of code (5 different lanuagues) per file). I feel the only reason i check the user group now is just to see the status on this proposal...and lo and behold, it didn't even make it into 1.1 compiled feature list for rejection. What a bummer. How much longer do we have to wait. I mean can someone just take a look at sqlalchemy and emulate it? I mean come on, you people are smart, why hasn't anyone done anything. In addition, opinionated as you are, it is not hard to just opinionate your way into a decision about how the admin portion should be handled and get on with the rest. Finally, dont the great JKM and Malcolms use composite primary keys...?!! (#U%)QU Alright, i feel better now. But still, come on, surprise our community a bit. (plus i mean the only reason anyone ever goes for Sqlalchemy, isn't it just for the composite key, and multi db support? (at least for me)) Frank On Nov 13, 9:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2008-11-14 at 00:17 -0500, Steve Holden wrote: > > [...] > > > Sure. Perhaps it's not common terminology: by "recursive" I meant a > > self-referential relationship, though now you mention it I see that the > > same issue can occur if the order of model definitions is sub-optimal. > > The recursive case is just a collapsed form of forwards references, so I > didn't address that specifically. You don't even need sub-optimal > ordering to require forwards references. For example, circular reference > loops (particularly with NULL relations) aren't unheard of. Even in > Django, you need forwards reference to implement the "through" option > for ManyToMany fields, since you need to define the intermediate model > with a ForeignKey to model A and then define model A with a many-to-many > through the intermediate model. So one of them has to be defined second. > All I'm saying is that forwards references crop up naturally; they're > not a wart (and references to the same model are the other obvious case > they crop up naturally). > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
