Re: Strange natural keys serialization XML format (Django SVN-12978)
Thank you for your advise. I created ticket regarding 1 and 3 to http://code.djangoproject.com/ticket/13418 On Apr 16, 4:12 pm, Russell Keith-Magee wrote: > On Fri, Apr 16, 2010 at 8:40 PM, h-k-ii wrote: > > You are correct. > > > Based on my experience with natural keys, I would propose improvements > > for the documentation [1] - but perhaps these are matters of personal > > opinion: > > We're always open to suggestions on how to improve documentation. The > best way to do this is to open a ticket describing the aspect that you > think needs to be improved (which is the list you've just given). > > Addressing your list specifically: > > > 1. mention requirement to use tuple also in serialization section > > (currently this is only mentioned in deserialization) > > This is certainly worth doing. > > > 2. rename "natural keys" to "natural relationship keys" (or similar). > > Current naming would suggest that pk fields would also use natural > > names > > I'm not sure I see the benefit here. The name "Natural Key" was chosen > because it mean something in database circles; I'm not sure I see how > the longer name you propose would clarify anything. > > > 3. in the example model define Person first_name and last_name as > > unique_together > > This is also probably worth doing - especially if we explain why > uniqueness is important in natural keys. > > > 4. perhaps use "return [self.first_name, self.last_name]" instead of > > "return (self.first_name, self.last_name)" in the example so that > > reader does not easily fall in to the trailing comma pitfall :) > > True, that does (technically) avoid the pitfall - however, a tuple and > a list aren't the same thing: > > http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constan...http://news.e-scribe.com/397 > > In this case, a tuple is the correct usage. > > > Thank you very much for your answer. It seems it takes more than a > > month to get to know with Python. > > Don't feel bad about that - I've been using Python for almost 10 years > now, and I'm *still* learning things ;-) > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Strange natural keys serialization XML format (Django SVN-12978)
On Fri, Apr 16, 2010 at 8:40 PM, h-k-ii wrote: > You are correct. > > Based on my experience with natural keys, I would propose improvements > for the documentation [1] - but perhaps these are matters of personal > opinion: We're always open to suggestions on how to improve documentation. The best way to do this is to open a ticket describing the aspect that you think needs to be improved (which is the list you've just given). Addressing your list specifically: > 1. mention requirement to use tuple also in serialization section > (currently this is only mentioned in deserialization) This is certainly worth doing. > 2. rename "natural keys" to "natural relationship keys" (or similar). > Current naming would suggest that pk fields would also use natural > names I'm not sure I see the benefit here. The name "Natural Key" was chosen because it mean something in database circles; I'm not sure I see how the longer name you propose would clarify anything. > 3. in the example model define Person first_name and last_name as > unique_together This is also probably worth doing - especially if we explain why uniqueness is important in natural keys. > 4. perhaps use "return [self.first_name, self.last_name]" instead of > "return (self.first_name, self.last_name)" in the example so that > reader does not easily fall in to the trailing comma pitfall :) True, that does (technically) avoid the pitfall - however, a tuple and a list aren't the same thing: http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/ http://news.e-scribe.com/397 In this case, a tuple is the correct usage. > Thank you very much for your answer. It seems it takes more than a > month to get to know with Python. Don't feel bad about that - I've been using Python for almost 10 years now, and I'm *still* learning things ;-) Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Strange natural keys serialization XML format (Django SVN-12978)
You are correct. Based on my experience with natural keys, I would propose improvements for the documentation [1] - but perhaps these are matters of personal opinion: 1. mention requirement to use tuple also in serialization section (currently this is only mentioned in deserialization) 2. rename "natural keys" to "natural relationship keys" (or similar). Current naming would suggest that pk fields would also use natural names 3. in the example model define Person first_name and last_name as unique_together 4. perhaps use "return [self.first_name, self.last_name]" instead of "return (self.first_name, self.last_name)" in the example so that reader does not easily fall in to the trailing comma pitfall :) Thank you very much for your answer. It seems it takes more than a month to get to know with Python. [1] http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys (I also discovered this by trial and error when I was trying to deserialize the data, but it was not possible to take back the question sent to moderation.) On Apr 16, 2:37 pm, Russell Keith-Magee wrote: > On Fri, Apr 16, 2010 at 5:26 PM, h-k-ii wrote: > > I find dumpdata output in XML format quite strange for natural keys. > > Each character in a key reference is wrapped in a . > > > Is this a bug to be reported or a feature? > > It certainly doesn't look right; so there is a bug somewhere. > > However, it might be in your code. I'm guessing from your serialized > output that your natural key is drawn from a a single string field on > your model. Is your natural_key() function defined as: > > def natural_key(self): > return self.name > > or as: > > def natural_key(self): > return (self.name,) > > The first is a string. The second is a tuple containing a single > element that is a string. Django is expecting the second form; > however, because strings are iterable objects, the first is also a > valid (albeit incorrect) natural key definition, consisting of as many > natural keys as there are letters in 'self.name'. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Strange natural keys serialization XML format (Django SVN-12978)
On Fri, Apr 16, 2010 at 5:26 PM, h-k-ii wrote: > I find dumpdata output in XML format quite strange for natural keys. > Each character in a key reference is wrapped in a . > > Is this a bug to be reported or a feature? It certainly doesn't look right; so there is a bug somewhere. However, it might be in your code. I'm guessing from your serialized output that your natural key is drawn from a a single string field on your model. Is your natural_key() function defined as: def natural_key(self): return self.name or as: def natural_key(self): return (self.name,) The first is a string. The second is a tuple containing a single element that is a string. Django is expecting the second form; however, because strings are iterable objects, the first is also a valid (albeit incorrect) natural key definition, consisting of as many natural keys as there are letters in 'self.name'. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Strange natural keys serialization XML format (Django SVN-12978)
I find dumpdata output in XML format quite strange for natural keys. Each character in a key reference is wrapped in a . Is this a bug to be reported or a feature? * >python manage.py dumpdata --format xml --natural appname ... Doctype1 ... D o c t y p e 1 (Django SVN-12978, Python 2.6.5, Windows XP) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.