Skip to content

Instantly share code, notes, and snippets.

@loic
Created December 5, 2013 10:39
Show Gist options
  • Save loic/7803299 to your computer and use it in GitHub Desktop.
Save loic/7803299 to your computer and use it in GitHub Desktop.
14:30 loic84: ping akaariai_
14:32 akaariai_: loic84: hi
14:32 loic84: akaariai_: hey, just spotted your comment on #21410.
14:32 ticketbot: https://code.djangoproject.com/ticket/21410
14:34 bouke has joined ([email protected])
14:34 loic84: can you think of way to express the multicolumn lookups with an example? I'd like to add a test case for it.
14:34 bouke: mYk: there appears to be a problem with the autoreloader on kqueue and PY3 -> https://github.com/django/django/blob/master/django/utils/autoreload.py#L173 bufsize is not a valid param on PY3
14:36 akaariai_: loic84: hmmh, not sure how to do that. Actually, if you give fk__in=instances in 1.6 it might be that multicolumn lookups are never involved
14:36 akaariai_: unless you have heavily modified FK field written in your project
14:37 bouke: mYk: refs #21420
14:37 ticketbot: https://code.djangoproject.com/ticket/21420
14:37 akaariai_: but I would still like to use fk__in if possible, it should be more reliable.
14:38 loic84: yeah that's what I think, but it's true that we shouldn't take the risk of adding a regression while fixing a regression.
14:38 akaariai_: for 1.7 + composite fields the situation of course changes. There I think we need to add the ability to do .filter(hidden_field__in=instances).
14:39 akaariai_: it shouldn't hurt anybody if you can do that as long as the user doesn't need to see or care about hidden field lookups.
14:39 akaariai_: loic84: yeah, I just try to be conservative when backpatching.
14:39 loic84: I wanted to discuss that with you the other day...
14:39 loic84: because hidden_field__in is the way to deal with composite field
14:40 loic84: otherwise we will duplicate heaps of work
14:40 akaariai_: loic84: yeah, I don't see any other clean solution.
14:40 loic84: but ... the hidden field is not hidden, it's non existant...
14:41 loic84: or we have to generate one off, disposable managers when we encounter such case.
14:42 akaariai_: I think all we need to do is add a ForeignObjectRel (or subclass thereof) for hidden fields to model._meta, and then have a good name for it.
14:43 akaariai_: all that field -> model._meta setup is somewhat complex so there might be problems ahead...
14:43 akaariai_: manager? I don't think we need managers, just the Rel?
14:45 bigkevmcd has joined ([email protected])
14:45 akaariai_: loic84: basically all we need is get_field_by_name('hidden_field') to return correct field + model combo, where the Field is some sort of Rel.
14:45 loic84: well for prefetching for example, that where we store the cache.
14:46 akaariai_: loic84: No, I don't think one should be able to prefetch stuff for hidden fields, but for reverse of hidden field prefech should work.
14:47 akaariai_: and for reverse of hidden field we do have the manager.
14:49 loic84: true, then yeah a mapping to rel in _meta should work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment