#19747: Admin save of non-default database model fails when model contains 
unique
fields
-------------------------------+---------------------------------------
     Reporter:  jay@…          |      Owner:  nobody
         Type:  Bug            |     Status:  new
    Component:  contrib.admin  |    Version:  1.4
     Severity:  Normal         |   Keywords:  multi-database admin save
 Triage Stage:  Unreviewed     |  Has patch:  0
Easy pickings:  0              |      UI/UX:  0
-------------------------------+---------------------------------------
 When I created the appropriate
 [https://docs.djangoproject.com/en/1.4/topics/db/multi-db/#exposing-
 multiple-databases-in-django-s-admin-interface admin.ModelAdmin] ,
 pointing to a different database (non-default), querying the database
 worked correctly. However, when trying to save, it would fail with the
 following message:

 (1146, "Table 'django_dev._Transactions' doesn't exist")

 The problem is that django_dev is the default database, not the database
 specified in the ModelAdmin. Here's my model admin definition:


 {{{
 class TransactionAdmin(admin.ModelAdmin):
     using = "salesdb"

     def save_model(self, request, obj, form, change):
         # Tell Django to save objects to the 'other' database.
         obj.save(using=self.using)

     def delete_model(self, request, obj):
         # Tell Django to delete objects from the 'other' database
         obj.delete(using=self.using)

     def queryset(self, request):
         # Tell Django to look for objects on the 'other' database.
         return super(TransactionAdmin,
 self).queryset(request).using(self.using)

     def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
         # Tell Django to populate ForeignKey widgets using a query
         # on the 'other' database.
         return super(TransactionAdmin,
 self).formfield_for_foreignkey(db_field, request=request,
 using=self.using, **kwargs)

     def formfield_for_manytomany(self, db_field, request=None, **kwargs):
         # Tell Django to populate ManyToMany widgets using a query
         # on the 'other' database.
         return super(TransactionAdmin,
 self).formfield_for_manytomany(db_field, request=request,
 using=self.using, **kwargs)
 }}}

 and here is my model definition (simplified):


 {{{
 class Transaction(models.Model):
     transactionId = models.IntegerField(primary_key=True,
 db_column='_TransactionID')
     transactionDate = models.DateField("Transaction date",
 db_column='_TransactionDate', default=datetime.now())
     customer = models.ForeignKey(Customer, db_column='_CustomerID')
     quantity = models.IntegerField(db_column='_Quantity', default=1)
     regName = models.CharField("Registered name", max_length=240,
 db_column='_RegName')
     regProdCode = models.CharField("Registered product", max_length=12,
 db_column='_RegProdCode', choices=PROD_CODE_CHOICES, default="INDM")
     regDate = models.DateField("Registration date", db_column='_RegDate',
 default=datetime.now())
     regKey = models.CharField("Registration code", max_length=90,
 db_column='_RegKey', blank=True, unique=True) # PROBLEM IS HERE
     ipAddress = models.GenericIPAddressField("IP address", max_length=60,
 db_column='_IPAddress', blank=True)

     def __unicode__(self):
         if self.transactionId:
             return "%i" % (self.transactionId,)
         return "None"

     class Meta:
         db_table = u'_Transactions'
 }}}


 I found that I had a field that was marked unique=True in the model. If I
 remove that, then everything works. I also used PyCharm to trace the
 problem into the code that was checking the uniqueness of the fields. The
 very odd thing is that if I break before the problem occurs, then step
 through it, it will in fact work. But when running with no breakpoints it
 fails every time. Not sure what that indicates.

 I can provide the full model if it will help - it's just pretty large.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/19747>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to