Field exceptions are silently passed when slicing geoqueryset

[Jani Tiainen]

When using GeoDjango exception happens when populating model from database using get().

x = MyModel.objects.get(pk=1)

Above works as expected, correct exception is thrown

But:

qs = MyModel.objects.filter(pk=1)
qs[0] 

Now IndexError exception is thrown instead of exception that was expected (in my particular case, there was invalid geometry).

Returned list from queryset itself is empty, no error thrown at all.

[Malcolm Tredinnick]

This isn't incorrect behaviour. The second example returns a Queryset. Always. It happens that the queryset is empty in your case. When you index into the queryset using a single index like this, it is treated the same as indexing into a list. You are asking for a non-existent element, so an IndexError is raised.

[Jani Tiainen]

>> x = MyModel.objects.get(pk=1)
>> TypeError: cannot set MyModel GeometryProxy with value of type: <class 'django.contrib.gis.geos.collections.MultiLineString'>

But

qs = MyModel.objects.filter(pk=1)

using qs.Count() with returns 1, but qs[0] returns IndexError. len(qs) raises TypeError again.

So Count(), len and slicing are not consistent.

[Jani Tiainen]

It seems that this is GeoQuerySet related problem only.

[mal]

Yes, slicing geoqueryset fails with IndexError when query result contains geometry field of incorrect type (e.g when model is defined with LineString but database contains MultiLineString).

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Anssi Kääriäinen]

I believe this is part of the more general "exceptions in queryset iteration are swallowed, empty list is returned" problem that has been resolved in master.