@#$%!.....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
-~----------~----~----~----~------~----~------~--~---

Reply via email to