Strange natural keys serialization XML format (Django SVN-12978)

[h-k-ii]

I find dumpdata output in XML format quite strange for natural keys.
Each character in a key reference is wrapped in a <natural>.

Is this a bug to be reported or a feature?

*

>python manage.py dumpdata --format xml --natural appname
...
<object pk="1" model="appname.documenttype">
<field type="CharField" name="name">Doctype1</field>
...
<object pk="2" model="appname.document">
<field to="appname.documenttype" name="datatype"
rel="ManyToOneRel">
<natural>D</natural>
<natural>o</natural>
<natural>c</natural>
<natural>t</natural>
<natural>y</natural>
<natural>p</natural>
<natural>e</natural>
<natural>1</natural>
</field>
</object>

(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...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Russell Keith-Magee]

On Fri, Apr 16, 2010 at 5:26 PM, h-k-ii <hunaj...@gmail.com> wrote:
> I find dumpdata output in XML format quite strange for natural keys.
> Each character in a key reference is wrapped in a <natural>.
>
> 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 %-)

[h-k-ii]

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 <freakboy3...@gmail.com>
wrote:

[Russell Keith-Magee]

On Fri, Apr 16, 2010 at 8:40 PM, h-k-ii <hunaj...@gmail.com> 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 ;-)

[h-k-ii]

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 <freakboy3...@gmail.com>
wrote:

> http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constan...http://news.e-scribe.com/397