IntegrityError in livesettings

[Alex Robbins]

When I try and save some settings at http://<store_url>/settings/ I am
getting this error

IntegrityError at /settings/

(1062, "Duplicate entry '1-PRODUCT-IMAGE_DIR' for key 2")

All I have done is try to change the product image directory.

When I changed that value back to its original value the error went
away, replaced by a new one:

IntegrityError at /settings/

(1062, "Duplicate entry '1-PAYMENT_DUMMY-CREDITCHOICES' for key 2")

I didn't even change this value.

Any ideas?

Thanks,
Alex

[Udbhav]

I am having this same problem

On Oct 24, 1:58 pm, Alex Robbins <alexander.j.robb...@gmail.com>
wrote:

> When I try and save some settings at http://<store_url>/settings/ I am
> getting this error
>

> IntegrityErrorat /settings/

>
> (1062, "Duplicate entry '1-PRODUCT-IMAGE_DIR' for key 2")
>
> All I have done is try to change the product image directory.
>
> When I changed that value back to its original value the error went
> away, replaced by a new one:
>

> IntegrityErrorat /settings/

[Alex Robbins]

Also, if I do a ./manage.py reset livesettings the problem goes
away...for a while. I can make all the changes I want. The next day
when I come back the settings have reverted to their original values.

Ideas?

[Chris Moffitt]

What cache back end are you using?

-Chris

[Alex Robbins]

memcached, using the cmemcache module.
--
Alex Robbins
5Q Communications, Inc.
http://www.5Qcommunications.com/
alex.r...@5Qcommunications.com
800-747-4214 ext 913 (p)
http://www.ask5q.com/twitter/

[Brian Tol]

We're also having problems with the db cache.

On Oct 29, 9:23 am, Alex Robbins <alexander.j.robb...@gmail.com>
wrote:

> memcached, using the cmemcache module.
> --
> Alex Robbins
> 5Q Communications, Inc.http://www.5Qcommunications.com/

> alex.robb...@5Qcommunications.com
> 800-747-4214 ext 913 (p)http://www.ask5q.com/twitter/

>
>
>
> On Wed, Oct 28, 2009 at 8:26 PM, Chris Moffitt <ch...@moffitts.net> wrote:
> > What cache back end are you using?
>
> > -Chris
>
> > On Wed, Oct 28, 2009 at 3:55 PM, Alex Robbins
> > <alexander.j.robb...@gmail.com> wrote:
>
> >> Also, if I do a ./manage.py reset livesettings the problem goes
> >> away...for a while. I can make all the changes I want. The next day
> >> when I come back the settings have reverted to their original values.
>
> >> Ideas?
>

[m1chael]

I think I had a similar problem when multiple django/satchmo sites
were trying to access the same cache DB/file

[Bruce Kroeze]

Does it pass a "./manage.py test livesettings" test run?

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

[Brian Tol]

Hi Bruce,

Yes, all 32 tests pass without a problem. I'll try to post a more
definitive definition of the problem in a bit (I'm looking at the code
right now)

-Brian

On Oct 29, 2:13 pm, Bruce Kroeze <bkro...@gmail.com> wrote:
> Does it pass a "./manage.py test livesettings" test run?
>
>
>
>
>
> On Thu, Oct 29, 2009 at 10:46 AM, m1chael <myk...@gmail.com> wrote:
>
> > I think I had a similar problem when multiple django/satchmo sites
> > were trying to access the same cache DB/file
>

> Bruce Kroezehttp://www.ecomsmith.com

[Brian Tol]

Hey Bruce,

Ok, I've figured out the source of the bug we're seeing, but I'm not
sure how to reproduce it in a test. Here's what we're seeing:

On line 47 in satchmo.apps.livesettings.models the cache-miss logic is
calling 'loading.app_cache_ready()' In our case that method is always
returning false. Thus, the database-value is never loaded, and Satchmo
creates a new Setting object in it's place. When this new setting is
saved to the db, it's triggering the IntegrityError.

I dug into the django.db.models.loading module a bit, and it appears
that a module/app someplace else in our codebase isn't loading
properly, and thus app_cache_ready() never finishes correctly. That
explains why we're seeing the problem in development but the tests
pass.

So, I'm assuming this isn't a Satchmo problem directly. However, this
_is_ the only side effect we've seen of whatever underlying problem
we're dealing with. The site works fine-as-is otherwise. I'm going to
keep digging, but I thought I'd document what we've found to-date.

Our temporary fix was to remove the call to 'loading.app_cache_ready
()' for now. Everything is working as expected.

Just out of curiosity, what's the benefit of using app_cache_ready()?

Thanks for the help and the great product!

-Brian

[Bruce Kroeze]

On Thu, Oct 29, 2009 at 1:12 PM, Brian Tol <wire...@gmail.com> wrote:
>
> Hey Bruce,

>
>
> Our temporary fix was to remove the call to 'loading.app_cache_ready
> ()' for now. Everything is working as expected.
>
> Just out of curiosity, what's the benefit of using app_cache_ready()?
>

IIRC, the app_cache_ready call is needed during a syncdb, especially
the first one. Some bootstrapping problem, I think. It has been a
while.