(2011-11-28 19:27:13) jpk: I've got two models, Spot and Property.  Spot has a PointField called location and Property has no geometry fields.  If I do spots=Spot.objects.all(), then later Property.objects.filter(spot__in=spots), it works fine.  However, if I do spots=Spot.objects.filter(location__contained=Polygon(...)), then when Property.objects.filter(spot__in=spots) is called, I get "'str' object has no attribute 'ewkb''.  I had a GeoManager on Spot, but not Property.  Everything I've read tells me putting a GeoManager on Property fixes that, but that didn't seem to make a difference.  Any idea why?
(2011-11-28 19:27:54) adamfast: jpk: you got cut off at "Everyt"
(2011-11-28 19:28:02) adamfast: but I'll say that all models should have GeoManager
(2011-11-28 19:28:11) adamfast: otherwise it doesn't know how to find stuff
(2011-11-28 19:28:24) adamfast: NOT just the single model with the geometry field
(2011-11-28 19:29:07) jpk: Dang, "Everything I've read tells me putting a GeoManager on Property fixes that, but that didn't seem to make a difference.  Any idea why?" :)
(2011-11-28 19:29:24) adamfast: oh sorry. let me reread
(2011-11-28 19:29:30) jpk: adamfast: Cut off at roughly the most important part of the question. :-P
(2011-11-28 19:29:31) adamfast: I saw a cut off and didn't read up to it
(2011-11-28 19:29:38) adamfast: indeed
(2011-11-28 19:29:40) jpk: s'all good
(2011-11-28 19:31:36) adamfast: ok so you added geomanager to the other one and still get the same error?
(2011-11-28 19:31:47) jpk: Correct
(2011-11-28 19:32:17) adamfast: ok. that's a different error than you'd expect from the geomanager issue anyway
(2011-11-28 19:33:34) adamfast: I'm trying to remember what the right way out of this is
(2011-11-28 19:33:47) adamfast: essentially it's trying to treat a string like it's a geometry
(2011-11-28 19:36:08) jpk: Oh, correction.  It's not when Property.objects.filter() is called, it's when the iterable that that returns is iterated on.  
(2011-11-28 19:38:06) jpk: http://pastebin.com/XL5XNDaN
(2011-11-28 19:41:12) adamfast: can you try what it shows at "The above code fragment could also be written as follows:" https://docs.djangoproject.com/en/1.3/ref/models/querysets/#in
(2011-11-28 19:41:28) adamfast: .values(pk) and then pass that in instead, basically
(2011-11-28 19:41:40) adamfast: I'm curious if something isn't setting up the relationship / join properly
(2011-11-28 19:45:34) jpk: http://pastebin.com/H9jHjWe0 Like that?
(2011-11-28 19:46:14) adamfast: lol
(2011-11-28 19:46:19) adamfast: the docs are WRONG
(2011-11-28 19:46:37) adamfast: take .query off. that'll blow up because it's returning you a string of the SQL being run :)
(2011-11-28 19:47:07) ***adamfast files a ticket. Good grief, what a process for six little characters
(2011-11-28 19:47:33) adamfast: no wait
(2011-11-28 19:47:50) jpk: Seems to do the same thing with/without .query, there.
(2011-11-28 19:48:08) adamfast: maybe it does magic and if it gets a query object switches to a subselect. clever.
(2011-11-28 19:48:28) adamfast: this is probably why they show it that way "If you pass in a ValuesQuerySet or ValuesListQuerySet (the result of calling values() or values_list() on a queryset) as the value to an __in lookup, you need to ensure you are only extracting one field in the result."
(2011-11-28 19:48:40) adamfast: it blows up if you forget to only get the pk
(2011-11-28 19:49:55) adamfast: but for you it blows up regardless
(2011-11-28 19:50:46) adamfast: I suspect you've found a bug in the ORM
(2011-11-28 19:51:53) jpk: Like, it works fine if I do spots = Spot.objects.all().  Only if I get spots using .filter(location__contained=...)
(2011-11-28 19:52:31) adamfast: right
(2011-11-28 19:53:58) jpk: Looks like any geo query does it.  Haven't tried all of them, but the first three or four do.