Composite Primary Keys - Django developers

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Composite Primary Keys
Received-SPF: pass (google.com: domain of dcra...@gmail.com designates 209.85.198.224 as permitted sender) client-ip=209.85.198.224;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=hAFga0BqOtSNbJ3CruUwbh9lOUi/DimZIfdmvDzQ/FdLjsXZiTF8b+JqmcHPZZIwdy
         gUYqS8Djq6HlivB21HKD5UlkXD9i9vDI+3k01WWfH8vt0Pxi45lqM+/Tz6eYsFuhMNvk
         7QDadQqAo7ch3yI39cc+5YO8pzuMH7VT6XpPw=
Message-ID: <f470871d0807271618x59911a78ta7afa0b607da08f2@mail.gmail.com>
Date: Sun, 27 Jul 2008 18:18:17 -0500
From: "David Cramer" <dcra...@gmail.com>
To: django-developers@googlegroups.com
Subject: Re: Composite Primary Keys
In-Reply-To: <1217200411.2877.34.ca...@lancre.tredinick.net>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9348_23243720.1217200697540"
References: <a23dc28a-3995-419c-bd0b-2a47dccda...@a70g2000hsh.googlegroups.com>
	 <1217200411.2877.34.ca...@lancre.tredinick.net>

------=_Part_9348_23243720.1217200697540
Content-Type: text/plain; charset=ISO-8859-1

The Meta attribute sounds ok, my ordering concept was based on the order
they are presented in the model definition. The one thing I don't like about
unique/primary key's in this situation, is that there are two ways to
declare them, and they differ based on if there's one or more than one. It's
one of those things that has always bothered me, but if there's no one
wanting to change unique_together and unique=bool, then I guess it makes
sense to add primary_keys as a Meta argument.

On Sun, Jul 27, 2008 at 6:13 PM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:

>
>
> On Sun, 2008-07-27 at 15:55 -0700, David Cramer wrote:
> > I'm to the point in a project where I *need* composite primary keys,
> > not using them would be a bit retarded and wasteful. So, I'm going to
> > write up the patch.
> >
> > Here's how I was doing it before QS-RF:
> >
> > - MyModel._meta.pk would return a tuple if it had multiple
> > - MyModel._meta.pks would always return a tuple
>
> It's be nice to do away with the need for the "pks" attribute, since it
> provides more than one way to do something. Yes, it means that sometimes
> you might need to test whether pk is a list or tuple, but that should be
> relatively rare.
>
> > - pk='hello' would still work as it does now
> > - pk=('hello,') would work
> > - pk=dict(field='hello') would work (to allow for unordered pk lists)
> > - Composite primary keys would be created simply by passing
> > primary_key=True as an argument on more than one field in your model.
>
> This won't work nicely, since it doesn't allow you to specify the order
> that will be used when assigning. Instead, for multi-column primary
> keys, I'd suggest specifying them as an attribute on Meta:
>
>        class Meta:
>           primary_keys = ('username', 'location')
>
> The order given there is the order used to specify them in assignments.
> Having to reorder fields in a model to do that otherwise (if you only
> used the primary_key attribute on the field) sets a kind of dangerous
> precedence, since it says that might be an okay approach, except nothing
> else can do it because ordering is then reserved for primary keys. We
> already have a few issues that arise out of managers being treated
> differently according to their order of declaration and it would be nice
> to avoid that in this new feature.
>
> > Anyone have any feedback, or started working on any code?
>
> I've got some code that is going to land in the next week (before the
> sprint, most likely) that adds most of the necessary support for
> multicolumn fields. This is primarily to fix a few bugs with generic
> relations in a non-specific way (it will work for all similar fields).
> The stuff I'd done on multi-pk work -- which I'm not going to finish
> before 1.0, because it's not that critical, so you're not duplicating
> anything I'm doing there -- seemed to work nicely on top of that. So you
> might want to keep an eye out for that. The main case where it's
> applicable is when somebody does filter(foo__pk=(1, 2, 3)) because you
> can no longer just replace "pk" with the name of the real attribute,
> instead you have to treat it as multiple columns.
>
> Regards,
> Malcolm
>
>
>
> >
>


-- 
David Cramer
Director of Technology
iBegin
http://www.ibegin.com/

------=_Part_9348_23243720.1217200697540
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">The Meta attribute sounds ok, my ordering concept was based on the order they are presented in the model definition. The one thing I don&#39;t like about unique/primary key&#39;s in this situation, is that there are two ways to declare them, and they differ based on if there&#39;s one or more than one. It&#39;s one of those things that has always bothered me, but if there&#39;s no one wanting to change unique_together and unique=bool, then I guess it makes sense to add primary_keys as a Meta argument.<br>
<br><div class="gmail_quote">On Sun, Jul 27, 2008 at 6:13 PM, Malcolm Tredinnick <span dir="ltr">&lt;<a href="mailto:malc...@pointy-stick.com">malc...@pointy-stick.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
On Sun, 2008-07-27 at 15:55 -0700, David Cramer wrote:<br>
&gt; I&#39;m to the point in a project where I *need* composite primary keys,<br>
&gt; not using them would be a bit retarded and wasteful. So, I&#39;m going to<br>
&gt; write up the patch.<br>
&gt;<br>
&gt; Here&#39;s how I was doing it before QS-RF:<br>
&gt;<br>
&gt; - MyModel._<a href="http://meta.pk" target="_blank">meta.pk</a> would return a tuple if it had multiple<br>
&gt; - MyModel._meta.pks would always return a tuple<br>
<br>
</div>It&#39;s be nice to do away with the need for the &quot;pks&quot; attribute, since it<br>
provides more than one way to do something. Yes, it means that sometimes<br>
you might need to test whether pk is a list or tuple, but that should be<br>
relatively rare.<br>
<div class="Ih2E3d"><br>
&gt; - pk=&#39;hello&#39; would still work as it does now<br>
&gt; - pk=(&#39;hello,&#39;) would work<br>
&gt; - pk=dict(field=&#39;hello&#39;) would work (to allow for unordered pk lists)<br>
&gt; - Composite primary keys would be created simply by passing<br>
&gt; primary_key=True as an argument on more than one field in your model.<br>
<br>
</div>This won&#39;t work nicely, since it doesn&#39;t allow you to specify the order<br>
that will be used when assigning. Instead, for multi-column primary<br>
keys, I&#39;d suggest specifying them as an attribute on Meta:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;class Meta:<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; primary_keys = (&#39;username&#39;, &#39;location&#39;)<br>
<br>
The order given there is the order used to specify them in assignments.<br>
Having to reorder fields in a model to do that otherwise (if you only<br>
used the primary_key attribute on the field) sets a kind of dangerous<br>
precedence, since it says that might be an okay approach, except nothing<br>
else can do it because ordering is then reserved for primary keys. We<br>
already have a few issues that arise out of managers being treated<br>
differently according to their order of declaration and it would be nice<br>
to avoid that in this new feature.<br>
<div class="Ih2E3d"><br>
&gt; Anyone have any feedback, or started working on any code?<br>
<br>
</div>I&#39;ve got some code that is going to land in the next week (before the<br>
sprint, most likely) that adds most of the necessary support for<br>
multicolumn fields. This is primarily to fix a few bugs with generic<br>
relations in a non-specific way (it will work for all similar fields).<br>
The stuff I&#39;d done on multi-pk work -- which I&#39;m not going to finish<br>
before 1.0, because it&#39;s not that critical, so you&#39;re not duplicating<br>
anything I&#39;m doing there -- seemed to work nicely on top of that. So you<br>
might want to keep an eye out for that. The main case where it&#39;s<br>
applicable is when somebody does filter(foo__pk=(1, 2, 3)) because you<br>
can no longer just replace &quot;pk&quot; with the name of the real attribute,<br>
instead you have to treat it as multiple columns.<br>
<br>
Regards,<br>
<font color="#888888">Malcolm<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>David Cramer<br>Director of Technology<br>iBegin<br><a href="http://www.ibegin.com/">http://www.ibegin.com/</a><br>
</div>

------=_Part_9348_23243720.1217200697540--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
