Created
December 5, 2013 10:39
-
-
Save loic/7803299 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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