On Tue, May 17, 2011 at 02:05:10AM -0700, akaariai wrote: > On May 12, 2:41 pm, Michal Petrucha <michal.petru...@ksp.sk> wrote: > > Due to the nature of this field type, other lookup filters than > > ``exact`` and ``in`` would have unclear semantics and won't be > > supported. The original plan was to also exclude support for ``in`` > > but as it turns out, ``in`` is used in several places under the > > assumption that primary keys support it, for example DeleteQuery > > or UpdateQuery. Therefore both filters will be implemented. > > I wonder how to implement __in lookups in SQLite3. SQLite3 doesn't > support where (col1, col2) in ((val3, val4),(val5, val6)). But other > DBs do (at least MySQL, Oracle and PostgreSQL). I do not know what > would be the best way to write something equivalent in SQLite3. The > obvious choice is to rewrite it as an OR lookup (as mentioned in the > full proposal). Maybe write it as an OR lookup for every DB for the > initial patch, and later on this can be improved to have per database > handling.
You're right, SQLite3 is the troublemaker here and the reason I wanted to leave these lookups out initially. Well, this depends on the level at which these lookups will be handled. The doable, albeit somewhat hacky way is to handle this when creating the SQL string for IN, recognize composite lookups and turn them into a disjunction. The more robust and probably "proper" way would be to delegate this to the database backend. The backend could then decite whether it wants (col1, col2) IN ((val1, val2), (val3, val4)) or ((col1 = val1) AND (col2 = val2)) OR ((col1 = val3) AND (col2 = val4)) This would, however, require enhancing the backend interface. I think I'll go with the first option, the second one would require even more non-trivial design decisions to be made regarding the backend interface and I think I have enough on my plate anyway. > In lookups with subselects are a harder problem. Those would > need to be rewritten as joined subselects with a distinct clause. [1] > Not in lookups could be still harder due to weird null handling. (1 > not in (null) -> Unknown). [2] > > I hope there will be an easy solution to this problem, as this feature > is something which would be really, really valuabe for Django (no more > telling DBAs: by the way, no composite foreign keys...). One simple > solution would be to disallow __in lookups with subselects (or run the > subselects separately) and use OR lookups when given a list of values. > This should be relatively easy to implement and could be improved > later on. Uh oh. This is black magic, probably heavily backend-dependent, too. I can tell for sure that I don't intend to incorporate any subquery support for composite lookups for now. Trying to do a composite __in lookup using a subquery will probably just throw an exception for now, the user will be required to evaluate it himself. Proper subquery support is something that can be addressed once the rest of the implementation is stable. Michal
signature.asc
Description: Digital signature
