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 p
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 s
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 othe
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
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 I
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
ll that said, there's a lot to like about your Index proposal.
> Perhaps there'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
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 have any of the
>
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 = models.FloatField()
> > a
uple or a namedtuple.
This way, the 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 Referencing
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
> semanti
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 can'
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
> wrote:
> > I would be nice if support for composite primary keys would be
> > implemented as a special case of general composite fields. There
> >
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'), db_index=True)
> a =
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)
On Wed, Mar 16, 2011 at 4: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. There would be no need for new
> Meta options:
>
> class Foo(Model):
> x = models.F
ble, and have db_index=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&qu
On Mar 16, 11:43 am, Christophe Pettus 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.
>
> It's appealing, but the rea
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 comp
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
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, are
> sensitive to the ordering of the fiel
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 the fields in the cla
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:
the order of the fi
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 the
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, Commenius University,
>> Brat
places in the
model layer as it is)
- 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, inspectdb would be also nice.
I&#
elations? The following post
suggests it might 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 s
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
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 from
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 the
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 w
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 disc
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
method
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
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, Davi
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
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 ar
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
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
multi
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 django-developers@goog
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 prov
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 fu
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, Au
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
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 make
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 pos
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 (http://code.d
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 workin
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
49 matches
Mail list logo
