Closed Ogreman closed 8 years ago
I don't think it's a good idea to implement every lookup by hand since we don't know what objects we're iterating over.
Consider the following case:
class Foo(object):
def bar(self, something):
return True if something in ['foo', 'bar'] else False
class User(object):
def __init__(self, children):
self.foo = Foo()
lifter.load(companies).filter(companies__users__foo=lambda v: v.bar('soup'))
Since we did not implement bar
on the IterableAttr
, the previous example will raise an AttributeError
.
Basically, anytime we try to get an attribute or a method on a nested object in lookups, it's to return a boolean.
Maybe we can find a clean way to proxy these calls on IterableAttr
to the underlying children, returning True if any of them return True ?
Is there a chance that something like this might be needed though?
lifter.load(companies).filter(companies__users__foo=lambda v: v.x == 'a')
Thinking perhaps this might do the trick:
def __call__(self, *args, **kwargs):
return self.__class__([item(*args, **kwargs) for item in self._items])
def __getattr__(self, name):
return self.__class__([getattr(item, name) for item in self._items])
Would allow for a filter like lambda v: v.bar('soup')
for example.
Just added an additional employee to the company tests and it causes the tests to fail.
Okay, so it's maybe a better idea to weak the query engine (instead of building highly-complex IterableAttr): if we're operating on an IterableAttr
object, just flatten it and run the match on underlying items. I'm working on this alternative.
An interesting issue regarding the whole query engine has been open (#15), we should probably wait for it to be resolved before continuing the work on this.
Closing for now as this is not needed after the Q objects are implemented.
Is missing tests for each of the lookups (WIP).