Tuesday, October 8, 2019

Re: QuerySet not iterable

Hello,

Thank your for your reply. I'm not using Python 2. I have attached the traceback as is emailed by Django to the Admin.

Traceback:

File "/home/user/api/env/lib/python3.6/site-packages/django/core/handlers/exception.py" in inner
  34.             response = get_response(request)

File "/home/user/api/env/lib/python3.6/site-packages/django/core/handlers/base.py" in _get_response
  115.                 response = self.process_exception_by_middleware(e, request)

File "/home/user/api/env/lib/python3.6/site-packages/django/core/handlers/base.py" in _get_response
  113.                 response = wrapped_callback(request, *callback_args, **callback_kwargs)

File "/home/user/api/env/lib/python3.6/site-packages/django/views/decorators/csrf.py" in wrapped_view
  54.         return view_func(*args, **kwargs)

File "/home/user/api/env/lib/python3.6/site-packages/django/views/generic/base.py" in view
  71.             return self.dispatch(request, *args, **kwargs)

File "/home/user/api/env/lib/python3.6/site-packages/rest_framework/views.py" in dispatch
  505.             response = self.handle_exception(exc)

File "/home/user/api/env/lib/python3.6/site-packages/rest_framework/views.py" in handle_exception
  465.             self.raise_uncaught_exception(exc)

File "/home/user/api/env/lib/python3.6/site-packages/rest_framework/views.py" in raise_uncaught_exception
  476.         raise exc

File "/home/user/api/env/lib/python3.6/site-packages/rest_framework/views.py" in dispatch
  502.             response = handler(request, *args, **kwargs)

File "/usr/lib/python3.6/contextlib.py" in inner
  52.                 return func(*args, **kwds)

File "/home/user/api/project/cashless/views/order.py" in post
  143.             order.save()

File "/home/user/api/project/payment_gateway/models.py" in save
  79.                 if ref_number not in transactions:

Exception Type: TypeError at [ENDPOINT]
Exception Value: argument of type 'QuerySet' is not iterable

I have did further testing and determined that my earlier hypothesis of select_for_update is not responsible for this error. The error persisted even after having removed that call.

I also figured that it the TypeError was mapping some internal system call and I did further testing and I realized the error is a TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.
That save happens inside of an atomic transaction. There are a couple of other select statements that are executed before this one (also inside the transaction). Though, I haven't been able to figure out what's wrong though.
Any leads would be appreciated.
Thank you.

On Tuesday, October 8, 2019 at 5:00:05 PM UTC+5:30, Simon Charette wrote:
Hello there,

From looking at your code (super() calls) it seems like your are using Python 2.

 We've seen similar reports about stdlib functions hiding system level exceptions
instead of surfacing them[0] so that might it.

It's hard to tell without the full traceback though.

Best,
Simon


Le lundi 7 octobre 2019 22:16:16 UTC-4, Abhijeet Viswa a écrit :
Hey guys,

I need a help with a quirky bug while iterating over a QuerySet:
TypeError: argument of type 'QuerySet' is not iterable

The following is the block of code that produces the error: (the save method overrides the default save method in a Model called Transaction)

def save(self, *args, **kwargs):
        obj
= self
       
if not obj.ref_number:  # the line of code throwing the error
            transactions
= Transaction.objects.values_list("ref_number", flat=True)     # cache the list
           
while True:
                ref_number
= random.randint(1000000001, 9999999999)
               
if ref_number not in transactions:
                    obj
.ref_number = ref_number
                   
super(Transaction, obj).save(*args, **kwargs)
                   
return
       
else:
           
super(Transaction, obj).save(*args, **kwargs)

This piece of code was working fine until we had modified (what we thought to be) an unrelated part of the source: (this is the modified line of code)
items = OrderItem.objects.prefetch_related('toppings').select_related('item').select_related('item__category')
order
= Order.objects.filter(uuid=order_uuid).prefetch_related(
           
Prefetch(
                lookup
='items',
                queryset
=items
           
)
       
).select_related('outlet').select_related('user').select_related('outlet__group') \
         
.select_for_update(of=('self', 'outlet'))


We basically added a call to the select_for_update. This was required by us since we are modifying both the Order as well as Outlet models. (Also, the Transaction model is a super-model for the Order model)

My best guess is that the select_for_update locks certain rows of the the Order, Transaction and a bunch of other models. This results in the line of code failing because the query to list the value fails. However, I tested this hypothesis out by running a select_for_update, populating the QuerySet returned and then sleeping for a while while I ran a different query on the Model for which rows were locked. This ran perfectly fine, with no problems.

We are using PostgreSQL as our backend database. Any help would be greatly appreciated.

Thanks

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e2324953-f85d-4f17-9889-ef433f5f1f71%40googlegroups.com.

No comments:

Post a Comment