Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- (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.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement