On Wed, Feb 13, 2013 at 9:51 PM, Kaloian <kaloian.min...@gmail.com> wrote:
>
> Hi Russell,
>
>
> Thanks for the responce! I actually found the problem it was not where I
> was looking for it and it was more of a typo.
> And your suggestion No.2 appears to be right:
>
> * Do you have any models with foreign keys to your custom user? (i.e., is
>> the problem manifesting when serialising Merchant, or serialising foreign
>> keys to Merchant?)
>>
>
> I am having a Product model with foreignkey to the Merchant model which
> had natural key method defined as follows:
>
> class Product(models.Model):
> name = models.CharField(max_length=200)
> #merchant = models.ForeignKey(Merchant, to_field='api_key')
> merchant = models.ForeignKey(Merchant)
> url = models.URLField(max_length = 2000)
> description = models.TextField(blank=True)
> client_product_id = models.CharField(max_length='100')
>
> objects = ProductManager()
> class Meta:
> verbose_name = 'Product'
> verbose_name_plural = 'Products'
> unique_together = ('merchant', 'client_product_id',)
>
> def __unicode__(self):
> return self.name
>
> def natural_key(self):
> return (self.merchant, self.client_product_id)
>
> The natural_key method returned self.merchant instead of self.merchant_id
> so it was trying to serialize the whole merchant object to make a natural
> key. After switching this to merchant_id it is working properly.
Glad you found the problem (and even more glad it isn't something I need to
fix :-)
> As a side note -- if you're using email as your username field, you should
>> set it as unique=True -- USERNAME_FIELD needs to be unique or you'll
>> experience problems later on. This is something that should probably be
>> caught by validation - which is a bug deserving of it's own report. For
>> performance reasons, you also probably want to set it db_index=True, since
>> you're going to be searching on that field fairly often, so having an index
>> on it makes sense.
>>
>
> Thanks for the notes I will for sure add these, but shouldn't both(unique
> and db_index) be added by default when you set your USERNAME_FIELD .
>
That's an interesting suggestion; I suppose it comes down to a question of
"explicit vs implicit". If being named in USERNAME_FIELD magically made the
field unique and indexed, the developer needs to implicitly know that this
will happen. If a developer actually *wanted* the username field to be
non-unique, they might get a surprise when they find that it isn't. Of
course, this points at a design problem on their end; the difference is
that if it is implicit, they will discover the problem by accident when a
non-unique username is rejected; if it is raised as a validation error,
they'll get an error when they sync their tables (giving them an indication
that the problem must be fixed).
I've opened ticket #19822 to track this problem.
Yours,
Russ Magee %-)
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
