settings assume pk=1

[jroo]

find a better way. don't rely on id, maybe enforce that only one setting record exists? possibly move settings out of database and into a file?

[rosskarchner]

I considered suggesting settings move to settings.py-- although I admit being able to edit them in the Wordpress admin is a nice feature of RAMP.

I'd be on board for migrating them to settings.py or a separate file if you agree.

[jroo]

Yeah, I like the ability to edit them in admin, too. Is it safe to assume pk will always be 1? Will the admin enforce this? If not should we enforce that just one record exists no matter what the id and just grab it?

[rosskarchner]

Right now admin does enforce it

On Feb 4, 2012, at 11:48 AM, Joshua Ruihleyreply@reply.github.com wrote:

Yeah, I like the ability to edit them in admin, too. Is it safe to assume pk will always be 1? Will the admin enforce this? If not should we enforce that just one record exists no matter what the id and just grab it?

---

Reply to this email directly or view it on GitHub:
https://github.com/jroo/django-nudge/issues/9#issuecomment-3811335

[jroo]

Nice. Does admin explicitly enforce that the id will always be 1 or does it just enforce one record (and the id could be anything)?

[rosskarchner]

It doesn't acknowledge that other settings objects might exist: if you try to add one or look at the list, it does a get_or_create for pk=1, and redirects you to edit it

On Feb 4, 2012, at 2:19 PM, Joshua Ruihleyreply@reply.github.com wrote:

Nice. Does admin explicitly enforce that the id will always be 1 or does it just enforce one record (and the id could be anything)?

---

Reply to this email directly or view it on GitHub:
https://github.com/jroo/django-nudge/issues/9#issuecomment-3812501

[jroo]

Thanks fo the clarification. I'm closing this since settings should assume that pk=1.

[rosskarchner]

http://word.bitly.com/post/19183796149/infrastructure-as-a-platform