Admin UI not commiting to DB

43 views
Skip to first unread message

Timothy W. Cook

unread,
Jul 12, 2014, 4:52:37 AM7/12/14
to django...@googlegroups.com
Django 1.65, PostgreSQL. 

Several users of the admin UI in my app have noted that clicking Save or Save and Continue buttons does not always actually save changes to the database. 

Has anyone else seen this?  I do override get_form in admin.py so that I can set some fields as readonly based on a boolean flag.  Otherwise my admin.py is pretty generic. 

Any hint as to where to look for this problem or the best approach to troubleshoot it?

--Tim

--

============================================
Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

Derek

unread,
Jul 12, 2014, 12:21:17 PM7/12/14
to django...@googlegroups.com
Tim

Hard to tell without code; but what happens when you test without the form override?  Also, unless you can reproduce the errors they get, then you will struggle to debug.  Have you tried adding in log statements at key points to try & see where things go haywire?

Timothy W. Cook

unread,
Jul 12, 2014, 7:05:00 PM7/12/14
to django...@googlegroups.com
Thanks for the reply Derek.  This post was just a stab to see if anyone had seen this before and I just missed the post.  

I guess it is time to roll up my sleeves and take a formal approach at debugging.  This one of VERY few, non-open source apps I work on.  Otherwise I would just point to the repository.  

When (if) I find the issue I will post a solution here.

Cheers,
Tim



--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f22690f1-cd8d-48f0-928d-7fe879efa57f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Derek

unread,
Jul 13, 2014, 1:32:51 PM7/13/14
to django...@googlegroups.com
I am sure that any update will help others who might have this issue.

I have been using the Django admin (on and off) for many years now and have not had this particular problem (yet).

It would also be useful to post more (non-confidential) details in a blog, perhaps.

Tom Evans

unread,
Jul 14, 2014, 11:45:44 AM7/14/14
to django...@googlegroups.com
On Sat, Jul 12, 2014 at 11:59 PM, Timothy W. Cook <t...@mlhim.org> wrote:
> Thanks for the reply Derek. This post was just a stab to see if anyone had
> seen this before and I just missed the post.
>
> I guess it is time to roll up my sleeves and take a formal approach at
> debugging. This one of VERY few, non-open source apps I work on. Otherwise
> I would just point to the repository.
>
> When (if) I find the issue I will post a solution here.
>
> Cheers,
> Tim
>

Have you ruled out that this is simply a mid air collision? IIRC,
django admin has no mid air collision detection system

Cheers

Tom

Eg if user A loads Item i, user B loads Item i, user A changes
i.foo='hi' and saves item i, user B sets i.foo='bar', i.wibble='quuz'.
User A complains that "admin is not saving my data".

Timothy W. Cook

unread,
Jul 15, 2014, 11:52:36 AM7/15/14
to django...@googlegroups.com
On Mon, Jul 14, 2014 at 12:44 PM, Tom Evans <teva...@googlemail.com> wrote:


Have you ruled out that this is simply a mid air collision? IIRC,
django admin has no mid air collision detection system

Cheers

Tom

Eg if user A loads Item i, user B loads Item i, user A changes
i.foo='hi' and saves item i, user B sets i.foo='bar', i.wibble='quuz'.
User A complains that "admin is not saving my data".


Thanks Tom.  I haven't had a chance to work on this yet.  However, I can reproduce it on my development machine with just one user.  
Even on the production machine we only have 3 - 5 users at a time and they are assigned different tasks and aren't likely to be editing the same entry.


I guess the obvious place that this would occur if no one else has the problem is in the get_form.  It really doesn't do much except check a boolean and determine if some fields should be readonly.

Example:

    def get_form(self, request, obj=None, **kwargs):
        try:
            if obj.published:
                self.readonly_fields = ['prj_name','published','lang','schema_code','data_name','valid_trues','valid_falses','description','sem_attr','resource_uri','asserts',]

        except (AttributeError, TypeError) as e:
            self.readonly_fields = ['published','schema_code','r_code',]

        return super(DvBooleanAdmin, self).get_form(request, obj, **kwargs)


The try/except was added at one point to see if I could prevent this issue.  It didn't make a difference so I'll probably take it out when I go back to working on it.  

I do have some actions defined but I can't see how they could cause this since it is happening during the standard  edit/save process. 

 
I don't recall if I said before: Django 1.6.5 (as well as earlier versions) PostgreSQL 9.2 and now 9.3 on Ubuntu 14.04 and previously CentOS 6.5 
Reply all
Reply to author
Forward
0 new messages