A fixture won't really solve the problem. I'm okay with Gabriel's
solution though. It is not as simple as my proposal, but certainly
more elegant.
Aditya
On Mar 13, 6:57 am, Chuck Harmston wrote:
> This particular use case (having predefined sets of information loaded
On Sat, Mar 13, 2010 at 6:27 PM, Chuck Harmston wrote:
> This particular use case (having predefined sets of information loaded into
> the database on either syncdb or other command) is what Django's fixture
> loading/creation system is for.
>
> Does this proposal add any functionality that fixtures do not already
> provide?
Convenience. It moves the definition of the site away from the
database, and away from fixtures files and into the settings.
Personally, I am yet to need multiple sites for a single database, and
would much prefer
This particular use case (having predefined sets of information loaded into
the database on either syncdb or other command) is what Django's fixture
loading/creation system is for.
http://docs.djangoproject.com/en/dev/ref/django-admin/#what-s-a-fixture
On Sat, Mar 13, 2010 at 3:56 PM, Gabriel Hurley wrote:
> "domain = Site.objects.get_current().domain"
>
> The "Site" model in that code comes from the
> django.contrib.sites.models, part of the Sites framework I mentioned
> above. This is not some bizarre buried database mishap;
"domain = Site.objects.get_current().domain"
The "Site" model in that code comes from the
django.contrib.sites.models, part of the Sites framework I mentioned
above. This is not some bizarre buried database mishap; this is the
app developer taking advantage of a contrib app that is included in