Re: follow relationship
http://code.djangoproject.com/wiki/CookBookChoicesContantsClass Feel free to fix any mistakes on the page! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Feel free to add it! --Ned. akaihola wrote: > Ned, I think this is definitely Django Cookbook stuff. It would perhaps > fit in http://code.djangoproject.com/wiki/CookBookDataModels > > I can add it for you if you're busy and allow me to... :) > > > > > > > . > > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Ned, I think this is definitely Django Cookbook stuff. It would perhaps fit in http://code.djangoproject.com/wiki/CookBookDataModels I can add it for you if you're busy and allow me to... :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Thanks a lot! I would have tried to do something with tuples, but this seems to make easy sense.ToddOn Mar 30, 2006, at 6:06 AM, Ned Batchelder wrote: Sorry, sent the email before the formatting was right: class K:
def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
) Now you can define ids and values, and optionally labels for each choice. --Ned. Ned Batchelder wrote: The choices= attribute in the model defines what goes into the select box. In this case, Constants.choices() returns a list based on the values based to the Constants constructor. My example below has it backwards for integers. It should be:def choices(self):
return [(v,k) for k,v in self.__dict__.items()]
Then for our example, the choices for Branch.kind would be [(1, 'main'), (2, 'aux'), (3, 'dead')], showing 'main', 'aux', 'dead' in the admin interface. Nicer labels than the Python identifiers wouldn't be possible with this code, you'd have to do something more elaborate:class K: def __init__(self, label=None, **kwargs): assert(len(kwargs) == 1) for k, v in kwargs.items(): self.id = k self.v = v self.label = label or self.id class Constants: def __init__(self, *args): self.klist = args for k in self.klist: setattr(self, k.id, k.v) def choices(self): return [(k.id, k.label) for k in self.klist] kBranchKind = Constants( K(main=1, label='Main branch'), K(dead=2, label='An ex-branch'), K(aux=3) # I don't know how to spell 'Auxilliary' anyway! ) Todd O'Bryan wrote: Wait. How do I define the user-friendly stuff that will show up in the select box for the admin interface?ToddOn Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote: What I've done in these cases is to define a Constants class: class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items()) (I guess Enumeration would be a better name), then I can define a list of constants: kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
) Then in the code, you can use kBranchKind.dead, and in your model, you can use: class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices()) It keeps the list of choices in one place, gives you run-time errors if you mistype the constant name (string literals would not), and it works just as well with strings for the values. --Ned. Ivan Sagalaev wrote: Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a --
Ned Batchelder, http://nedbatchelder.com
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users
Re: follow relationship
And there's a bug! The body of choices() should be:
def choices(self):
return [(k.v, k.label) for k in self.klist]
Ned Batchelder wrote:
Sorry, sent the email before the formatting was right:
class K:
def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
)
Now you can define ids and values, and optionally labels for each
choice.
--Ned.
Ned Batchelder wrote:
The choices= attribute in the model defines what goes into the select
box. In this case, Constants.choices() returns a list based on the
values based to the Constants constructor. My example below has it
backwards for integers. It should be:
def choices(self):
return [(v,k) for k,v in self.__dict__.items()]
Then for our example, the choices for Branch.kind would be [(1,
'main'), (2, 'aux'), (3, 'dead')], showing 'main', 'aux', 'dead' in the
admin interface. Nicer labels than the Python identifiers wouldn't be
possible with this code, you'd have to do something more elaborate:
class K: def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
)
Todd O'Bryan wrote:
Wait. How do I define the user-friendly stuff that will
show up in the select box for the admin interface?
Todd
On Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote:
What I've done in these cases is to
define
a
Constants class:
class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items())
(I guess Enumeration would be a better name), then I can define a list
of constants:
kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
)
Then in the code, you can use kBranchKind.dead, and in your model, you
can use:
class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices())
It keeps the list of choices in one place, gives you run-time errors if
you mistype the constant name (string literals would not), and it works
just as well with strings for the values.
--Ned.
Ivan Sagalaev wrote:
Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a
--
Ned Batchelder, http://nedbatchelder.com
--
Ned Batchelder, http://nedbatchelder.com
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscrib
Re: follow relationship
Sorry, sent the email before the formatting was right:
class K:
def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
)
Now you can define ids and values, and optionally labels for each
choice.
--Ned.
Ned Batchelder wrote:
The choices= attribute in the model defines what goes into the select
box. In this case, Constants.choices() returns a list based on the
values based to the Constants constructor. My example below has it
backwards for integers. It should be:
def choices(self):
return [(v,k) for k,v in self.__dict__.items()]
Then for our example, the choices for Branch.kind would be [(1,
'main'), (2, 'aux'), (3, 'dead')], showing 'main', 'aux', 'dead' in the
admin interface. Nicer labels than the Python identifiers wouldn't be
possible with this code, you'd have to do something more elaborate:
class K: def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
)
Todd O'Bryan wrote:
Wait. How do I define the user-friendly stuff that will
show up in the select box for the admin interface?
Todd
On Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote:
What I've done in these cases is to define
a
Constants class:
class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items())
(I guess Enumeration would be a better name), then I can define a list
of constants:
kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
)
Then in the code, you can use kBranchKind.dead, and in your model, you
can use:
class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices())
It keeps the list of choices in one place, gives you run-time errors if
you mistype the constant name (string literals would not), and it works
just as well with strings for the values.
--Ned.
Ivan Sagalaev wrote:
Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a
--
Ned Batchelder, http://nedbatchelder.com
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
The choices= attribute in the model defines what goes into the select
box. In this case, Constants.choices() returns a list based on the
values based to the Constants constructor. My example below has it
backwards for integers. It should be:
def choices(self):
return [(v,k) for k,v in self.__dict__.items()]
Then for our example, the choices for Branch.kind would be [(1,
'main'), (2, 'aux'), (3, 'dead')], showing 'main', 'aux', 'dead' in the
admin interface. Nicer labels than the Python identifiers wouldn't be
possible with this code, you'd have to do something more elaborate:
class K: def __init__(self, label=None, **kwargs):
assert(len(kwargs) == 1)
for k, v in kwargs.items():
self.id = k
self.v = v
self.label = label or self.id
class Constants:
def __init__(self, *args):
self.klist = args
for k in self.klist:
setattr(self, k.id, k.v)
def choices(self):
return [(k.id, k.label) for k in self.klist]
kBranchKind = Constants(
K(main=1, label='Main branch'),
K(dead=2, label='An ex-branch'),
K(aux=3) # I don't know how to spell 'Auxilliary' anyway!
)
Todd O'Bryan wrote:
Wait. How do I define the user-friendly stuff that will
show up in the select box for the admin interface?
Todd
On Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote:
What I've done in these cases is to define a
Constants class:
class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items())
(I guess Enumeration would be a better name), then I can define a list
of constants:
kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
)
Then in the code, you can use kBranchKind.dead, and in your model, you
can use:
class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices())
It keeps the list of choices in one place, gives you run-time errors if
you mistype the constant name (string literals would not), and it works
just as well with strings for the values.
--Ned.
Ivan Sagalaev wrote:
Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Wait. How do I define the user-friendly stuff that will show up in the select box for the admin interface?ToddOn Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote: What I've done in these cases is to define a Constants class: class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items()) (I guess Enumeration would be a better name), then I can define a list of constants: kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
) Then in the code, you can use kBranchKind.dead, and in your model, you can use: class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices()) It keeps the list of choices in one place, gives you run-time errors if you mistype the constant name (string literals would not), and it works just as well with strings for the values. --Ned. Ivan Sagalaev wrote: Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a box in admin and in automatic manipulators
(if I'm not mistaken). A lookup table for branch kinds would solve this:
class BranchKind(meta.Model):
id = meta.SlugField(primary_key=True)
title = meta.CharField(maxlength=50)
You can then do something like
trunk.get_branch(pk='dead')
.
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Wow. That's very elegant. I'm loving the Python.ToddOn Mar 29, 2006, at 9:59 PM, Ned Batchelder wrote: What I've done in these cases is to define a Constants class: class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items()) (I guess Enumeration would be a better name), then I can define a list of constants: kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
) Then in the code, you can use kBranchKind.dead, and in your model, you can use: class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices()) It keeps the list of choices in one place, gives you run-time errors if you mistype the constant name (string literals would not), and it works just as well with strings for the values. --Ned. Ivan Sagalaev wrote: Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a box in admin and in automatic manipulators
(if I'm not mistaken). A lookup table for branch kinds would solve this:
class BranchKind(meta.Model):
id = meta.SlugField(primary_key=True)
title = meta.CharField(maxlength=50)
You can then do something like
trunk.get_branch(pk='dead')
.
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
What I've done in these cases is to define a Constants class:
class Constants:
""" Construct one of these with keyword arguments, and you can use the
attributes.
"""
def __init__(self, **kwargs):
for k, v in kwargs.items():
setattr(self, k, v)
def choices(self):
return list(self.__dict__.items())
(I guess Enumeration would be a better name), then I can define a list
of constants:
kBranchKind = Constants(
main = 1,
aux = 2,
dead = 3
)
Then in the code, you can use kBranchKind.dead, and in your model, you
can use:
class Branch(meta.Model):
trunk = meta.ForeignKey(Trunk)
kind = meta.IntegerField(choices=kBranchKind.choices())
It keeps the list of choices in one place, gives you run-time errors if
you mistype the constant name (string literals would not), and it works
just as well with strings for the values.
--Ned.
Ivan Sagalaev wrote:
Todd O'Bryan wrote:
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a box in admin and in automatic manipulators
(if I'm not mistaken). A lookup table for branch kinds would solve this:
class BranchKind(meta.Model):
id = meta.SlugField(primary_key=True)
title = meta.CharField(maxlength=50)
You can then do something like
trunk.get_branch(pk='dead')
.
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: follow relationship
Todd O'Bryan wrote:
>Your comment at the end got me thinking, though. Writing
>
>trunk.get_branch(kind__exact=2)
>
>is not very illuminating, but you're correct that the value 'Dead'
>could get changed later. In Java, I'd use constants for the integer
>values
>
>public static final int DEAD = 2;
>
>but that seems to violate DRY, because the semantics is already
>listed in the choices list. I like using integers for what end up
>being enumerated types because they don't take much space in the
>database and, as you mentioned, it's easy to change the English
>version without having to do anything to the db representation.
>
>Is there a better way to do this kind of thing?
>
>
This got me thinking too :-)
Generally when I need a constant in Python I don't hesitate to use
string values for constants which are both values and names. So I'd have
BRANCH_KINDS = (('main', 'Main'), ('aux', 'Auxiliary'), ('dead',
'Dead'),)
I think it won't even hurt performance in DB lookups if you create index
for this field. However this implies changing the field to CharField
which won't become a box in admin and in automatic manipulators
(if I'm not mistaken). A lookup table for branch kinds would solve this:
class BranchKind(meta.Model):
id = meta.SlugField(primary_key=True)
title = meta.CharField(maxlength=50)
You can then do something like
trunk.get_branch(pk='dead')
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---
Re: follow relationship
On Mar 27, 2006, at 11:40 PM, Ivan Sagalaev wrote:
>
> Todd O'Bryan wrote:
>
>> The tutorial explains how to get objects based on field values, but I
>> need to get a subset of the objects in a OneToMany relationship based
>> on one of their values. Here's an example:
>>
>> BRANCH_KINDS = ((0, 'Main'), (1, 'Auxiliary'), (2, 'Dead'),)
>>
>> class Trunk(meta.Model):
>> name = meta.CharField(max_length=10)
>>
>> class Branch(meta.Model):
>> trunk = meta.ForeignKey(Trunk)
>> kind = meta.IntegerField(choices=BRANCH_KINDS)
>>
>> Say I have a Trunk object and want to get all of its Auxiliary
>> branches. How the heck do I do that?
>>
>>
> Since your DB doesn't know anything about BRANCH_KINDS values you
> should
> manually find a number corresponding a value and use it for lookup:
>
> from myproject.myapp.models import BRANCH_KINDS
>
> index = [bk[1] for bk in BRANCH_KINDS].index('Auxillary')
> trunks.get_branch_list(kind__exact=BRANCH_KINDS[index][0])
>
> But it anyway looks strange that you need to make a DB lookup based on
> values intended only for display purposes and that can be changed
> any time.
Thanks. It was the second line I couldn't figure out. (Simple in
hindsight.)
Your comment at the end got me thinking, though. Writing
trunk.get_branch(kind__exact=2)
is not very illuminating, but you're correct that the value 'Dead'
could get changed later. In Java, I'd use constants for the integer
values
public static final int DEAD = 2;
but that seems to violate DRY, because the semantics is already
listed in the choices list. I like using integers for what end up
being enumerated types because they don't take much space in the
database and, as you mentioned, it's easy to change the English
version without having to do anything to the db representation.
Is there a better way to do this kind of thing?
Todd
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---
Re: follow relationship
Todd O'Bryan wrote:
>The tutorial explains how to get objects based on field values, but I
>need to get a subset of the objects in a OneToMany relationship based
>on one of their values. Here's an example:
>
>BRANCH_KINDS = ((0, 'Main'), (1, 'Auxiliary'), (2, 'Dead'),)
>
>class Trunk(meta.Model):
> name = meta.CharField(max_length=10)
>
>class Branch(meta.Model):
> trunk = meta.ForeignKey(Trunk)
> kind = meta.IntegerField(choices=BRANCH_KINDS)
>
>Say I have a Trunk object and want to get all of its Auxiliary
>branches. How the heck do I do that?
>
>
Since your DB doesn't know anything about BRANCH_KINDS values you should
manually find a number corresponding a value and use it for lookup:
from myproject.myapp.models import BRANCH_KINDS
index = [bk[1] for bk in BRANCH_KINDS].index('Auxillary')
trunks.get_branch_list(kind__exact=BRANCH_KINDS[index][0])
But it anyway looks strange that you need to make a DB lookup based on
values intended only for display purposes and that can be changed any time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---
follow relationship
The tutorial explains how to get objects based on field values, but I need to get a subset of the objects in a OneToMany relationship based on one of their values. Here's an example: BRANCH_KINDS = ((0, 'Main'), (1, 'Auxiliary'), (2, 'Dead'),) class Trunk(meta.Model): name = meta.CharField(max_length=10) class Branch(meta.Model): trunk = meta.ForeignKey(Trunk) kind = meta.IntegerField(choices=BRANCH_KINDS) Say I have a Trunk object and want to get all of its Auxiliary branches. How the heck do I do that? Todd --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
