Re: Primary keys vs. natural keys

2014-10-31 Thread Carl Meyer 

> On Oct 31, 2014, at 3:26 PM, Torsten Bronger  
> wrote:
> 
> Hallöchen!
> 
> Carl Meyer writes:
> 
>>> On Oct 31, 2014, at 4:19 AM, Torsten Bronger 
>>>  wrote:
>>> 
>>> [...]
>>> 
>>> Do you mean this:
>>> 
>>>   class ExternalOperator(models.Model):
>>> 
>>>   name = models.CharField(_("name"), max_length=30, unique=True)
>>>   natural_key_field = "name"
>>> 
>>> It works (at least, it doesn't abort) but I thought only fields
>>> were allowed as attributes.
>> 
>> Yes, that's what I mean (though usually for clarity I would place
>> any non-field attributes in a separate visual block - separated by
>> a blank line - from field attributes). There is no requirement
>> that all class attributes of models must be fields. Django can
>> tell which are subclasses of Field and ignores the others.
> 
> See https://code.djangoproject.com/ticket/5793 -- can't this be
> solved by such attributes then?  I wonder because I subscribed to
> this ticket long ago for a similar reason.

True - there's nothing you could do with custom Meta attributes that can't just 
as well be done with class attributes. The desire for custom Meta attributes is 
purely a matter of API aesthetics. 

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/80F5A802-AC01-4137-B3C0-B8DFC67D3F4D%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Primary keys vs. natural keys

2014-10-31 Thread Torsten Bronger 
Hallöchen!

Carl Meyer writes:

>> On Oct 31, 2014, at 4:19 AM, Torsten Bronger  
>> wrote:
>>
>> [...]
>> 
>> Do you mean this:
>> 
>>class ExternalOperator(models.Model):
>> 
>>name = models.CharField(_("name"), max_length=30, unique=True)
>>natural_key_field = "name"
>> 
>> It works (at least, it doesn't abort) but I thought only fields
>> were allowed as attributes.
>
> Yes, that's what I mean (though usually for clarity I would place
> any non-field attributes in a separate visual block - separated by
> a blank line - from field attributes). There is no requirement
> that all class attributes of models must be fields. Django can
> tell which are subclasses of Field and ignores the others.

See https://code.djangoproject.com/ticket/5793 -- can't this be
solved by such attributes then?  I wonder because I subscribed to
this ticket long ago for a similar reason.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/87r3xogccd.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: Primary keys vs. natural keys

2014-10-31 Thread Carl Meyer 

> On Oct 31, 2014, at 4:19 AM, Torsten Bronger  
> wrote:
> Carl Meyer writes:
>> [...]
>> 
>> There is no built in feature for this, but it doesn't seem like a
>> hard problem to solve with your own conventions. For instance,
>> rather than hardcoding the name of the natural key field inside
>> the natural_key method, make it a model class attribute,
>> e.g. MyModel.natural_key_field.
> 
> Do you mean this:
> 
>class ExternalOperator(models.Model):
> 
>name = models.CharField(_("name"), max_length=30, unique=True)
>natural_key_field = "name"
> 
> It works (at least, it doesn't abort) but I thought only fields were
> allowed as attributes.

Yes, that's what I mean (though usually for clarity I would place any non-field 
attributes in a separate visual block - separated by a blank line - from field 
attributes). There is no requirement that all class attributes of models must 
be fields. Django can tell which are subclasses of Field and ignores the 
others. 

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9EE3479F-0830-46B6-82E1-6B197C48B230%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Primary keys vs. natural keys

2014-10-31 Thread Torsten Bronger 
Hallöchen!

Carl Meyer writes:

> [...]
>
> There is no built in feature for this, but it doesn't seem like a
> hard problem to solve with your own conventions. For instance,
> rather than hardcoding the name of the natural key field inside
> the natural_key method, make it a model class attribute,
> e.g. MyModel.natural_key_field.

Do you mean this:

class ExternalOperator(models.Model):

name = models.CharField(_("name"), max_length=30, unique=True)
natural_key_field = "name"

It works (at least, it doesn't abort) but I thought only fields were
allowed as attributes.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8738a4h78e.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: Primary keys vs. natural keys

2014-10-31 Thread Carl Meyer 
Hi Torsten,

> On Oct 31, 2014, at 3:13 AM, Torsten Bronger  
> wrote:
> Do I understand it correctly that in the Django community, it is
> preferred to use surrogate primary keys (the auto ID field) instead
> of explicitly setting primary keys?  

Yes, I'd say this is true.

> Currently, I add natural_key()
> methods to many of my models, but some of them return only one
> field.  Now I wonder whether I made a mistake and should have chosen
> that field as the primary key.
> 
> My use case is that I need to retrieve the natural keys of all
> objects in the database of a particular model.  As far as I can see,
> this can only be achieved by fetching all objects and calling the
> natural_key() method for all of them.  In contrast,
> 
>model.objects.values_list("pk", flat=True)
> 
> is probably *much* faster.
> 
> Is it possibly to specify a single field a natural key somehow
> (besides making it the PK)?  For example, it is possible to add a
> Meta attribute to the model?

There is no built in feature for this, but it doesn't seem like a hard problem 
to solve with your own conventions. For instance, rather than hardcoding the 
name of the natural key field inside the natural_key method, make it a model 
class attribute, e.g. MyModel.natural_key_field. Then the natural_key method 
can return getattr(self, self.natural_key_field) (you could even implement this 
method just once in an abstract base or mixin), and you can also use the 
attribute to do your efficient query: 
MyModel.objects.values_list(MyModel.natural_key_field, flat=True)

There may be reasons to consider natural primary keys in your data model 
(though personally I think surrogates are usually a better choice), but I don't 
think the problem you presented implies that you made the wrong choice. 

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7EC7C040-056D-422F-BE10-0707F72F230C%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Primary keys vs. natural keys

2014-10-31 Thread Torsten Bronger 
Hallöchen!

Do I understand it correctly that in the Django community, it is
preferred to use surrogate primary keys (the auto ID field) instead
of explicitly setting primary keys?  Currently, I add natural_key()
methods to many of my models, but some of them return only one
field.  Now I wonder whether I made a mistake and should have chosen
that field as the primary key.

My use case is that I need to retrieve the natural keys of all
objects in the database of a particular model.  As far as I can see,
this can only be achieved by fetching all objects and calling the
natural_key() method for all of them.  In contrast,

model.objects.values_list("pk", flat=True)

is probably *much* faster.

Is it possibly to specify a single field a natural key somehow
(besides making it the PK)?  For example, it is possible to add a
Meta attribute to the model?

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/87egtoha9w.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.