Code

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#17243 closed Bug (needsinfo)

running syncdb alters table django_site (replaces site info with "example")

Reported by: nikita.delyukov@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.2
Severity: Normal Keywords: syncdb
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

running syncdb alters table django_site (replaces site info with "example.com", "example site").
everytime syncdb is run have to go to admin to revert site info

Attachments (0)

Change History (4)

comment:1 Changed 2 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to needsinfo
  • Status changed from new to closed

I cannot recreate this behavior. The code that creates the "example" site is create_default_site in django.contrib.sites.management.py. Back in 1.2 (the version set for this ticket) that code was: https://code.djangoproject.com/browser/django/tags/releases/1.2/django/contrib/sites/management.py#L9. It's a signal handler attached to the syncdb signal, but it only creates the example site object if the Site table was among those created by this syncdb run. Also, even if that 1.2 level code mistakenly ran when the Site table already existed and that example site had been customized to have a different name & domain, that 1.2 level code would not replace the customized instance but rather just add another one (which would have a different PK than what is specified as SITE_ID in settings) with the "example" name & domain. I think there must be more to the story than what has been reported here, because I can neither recreate in trying nor see by looking at the code how what has been reported could be happening. Is there any way your syncdb is being preceded by something that causes the existing Site table to be dropped before the syncdb?

comment:2 Changed 2 years ago by nikita.delyukov@…

It was all about fixtures.
Site's based on Pinax 0.7 which was supplied with a file web/fixtures/initial_data.json with

"model": "sites.site", 
         "fields": {
            "domain": "example.com", 
            "name": "Example Site"
         }

Don't know how it agrees with what you said about syncdb not able to alter data, but the case's closed.

comment:3 Changed 2 years ago by kmtracey

I did not say that syncdb can't alter data, I said that the piece of code I found within Django 1.2 level that creates the "example" site would not alter an existing site instance that was configured to have a different name after its creation. Fixtures, on the other hand, will overwrite data. That fixture is not a Django thing, it's a Pinax thing, and it will apparently overwrite the Site with pk=1 (though you seem to have omitted the PK from the fixture data). The reason for this initial data fixture existing was discussed on the Pinax list: http://groups.google.com/group/pinax-users/browse_thread/thread/f485bb534486ba56. You are apparently supposed to configure the correct value for your site correctly before running syncdb, rather than changing it in the DB afterwards.

comment:4 Changed 2 years ago by anonymous

I see, couldn't find this discussion in google.
Thanks for your help!

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.