Thank you for your intereset this on feature. I belive this functionality should not delegete everything to database: one of the cooliest Django features is that models do not require database: they could be just storage of *business* logic (that is why we call them *fat*). I can even fill my models from different source and logic will still exist:
customer = Customer(age=variable_from_csv_file) if customer.is_allowed_to_drink: .... But I agree that reflecting *all* database features could be cumbersome. We can limit usage to simple stuff like "eq", "gt(e)", and "contains" and literals as arguments. I also do not think that we should ask user to use lambdas: "CalculatedField(Q(age__gte=18), lambda c: c.age >= 18)" literally violates DRY (one of the key Django features after all!) But we can give user ability to provide custom lambda (for advanced cases) Actually, my idea about lambdas was about to make calculation "lazy" "still_actual = Event(Q(end_of_like__lt=date.today())" I want "today" to be calculated at the moment when method is called or SQL query executed. Something like "still_actual = Event(lambda expression_api: expression_api.expression(end_of_like__lt=date.today())" It looks ugly, we can create some sugar for it. I really like how SQLAlchemy does it. They say "It can, in theory, work with any descriptor-based expression system". Can we borrow it? Ilya. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/632c3d33-48c8-437e-877f-21eeb2121d72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
