Re: models.CalculatedField feature
Thank you all. I've created a feature request https://code.djangoproject.com/ticket/28822 and will try to implement in my Django fork next week. I am not Django source code guru, so any help is welcome:) -- 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/3fce9746-f09b-4f01-8d98-b71450f7ee95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: models.CalculatedField feature
Ok, can we have
is_adult = models.DBCalculatedField(ExpressionWrapper(Q(age__gt=18),
output_field=BooleanField()))
Any query for model with this field will be automatically annotated with
.annotate(is_adult =ExpressionWrapper(Q(age__gt=18),
output_field=BooleanField()))
We may use F fields also, something like
full_name = models.DBCalculatedField(ExpressionWrapper(F('first_name') +
F('last_name'), output_field=CharField()))
We may simplify it to
is_adult = models.DBCalculatedField(expr=Q(age__gt=18),
output_field=BooleanField()))
It will work for any object, created from database.
For local computation we may give user ability to provide lambda or
decorate method (as in your example).
After it, I can create my own mixin as *third party lib* to patch model
with DBCalculatedField and calcuate its expression locally.
class Customer(models.Model, UnsafeCalculateDbLocallyMixin):
age = models.IntegerField()
is_adult = models.DBCalculatedField(expr=Q(age__gt=18),
output_field=BooleanField()))
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/b659a3a8-40a0-4863-ae00-38d3c2c13c22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: models.CalculatedField feature
Ok, I see not everyone are happy with idea of ORM expression calculated on
Python side:)
We can:
* Provide two different backends (Database-based and Python-based or "run
python in database" backend) for calculated field
* Or provide python-based backend as third party lib
* Or provide whole solution as third party lib (if Django API is flexible
enough for that)
I still do not like database approach.
* If I have list of objects, do you want to have O(n) queries?
* If calculated field is function of only model fields (no foreign keys
etc) it should work locally: some projects may have no database at all.
>>Even simple comparisons can be difficult to simulate in Python. As an
example, some databases treat empty strings as null
But ORM should handle it somehow, should not it?
I want to belive that "filter(alias__isnull=True)" works identically across
all databases.
So, we need to do same on Python side.
>>To be honest, I'm curious why the SQLAlchemy approach isn't being
discussed more here.
I think SQLAlchemy approach is good, but we should use Django ORM
expressions language.
See: we need some high-level expression language to describe functions of
models that could be
calculated both on SQL side and Python side.
And we already have it: it is Django ORM expressions language:)
We have some kind of AST for all those Q, F expressions etc, so we only
need to create evaluator for this language.
No need to use external language, based on Python, as SQLAlchemy does.
Why do we need
from sqlalchemy import func
func.concat(cls.first_name, ' ', cls.last_name)
if we already have
F('first_name') + F('last_name')
?
>>and supplying both the SQL side (via a method which returns a Q object,
most likely) and the Python side
But it ruin DRY idea by making author to write same logic twice (for Python
and SQL), is not it?
Still, user may have ability to provide custom expression,
but for simple cases like "age__gt=18" we can do it "automagically".
Django generates SQL code from its expressions. Sometimes this code is
sophisticated.
Why can't we do that for Python, if we do it for SQL?
--
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/797db487-be9a-4f2d-a6d5-330b1b891374%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [off topic] Re: models.CalculatedField feature
> > Such computations always end up slightly different in some > edge cases > I agree. We can document this fact. Model authors should be aware that they are not allowed to use anything but literals. All other functions are used on their own risc. I believe that comparition of two integers or strings should work stable across all modern platforms. I still believe database shall not be involved in this process.I do not need database to compare two digits. -- 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/ff53c2f9-37af-42d8-b412-3e9db6b60b6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: models.CalculatedField feature
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.
models.CalculatedField feature
Hello.
I think I just invented very useful feature.
I have the following model
class Customer(models.Model):
age = models.IntegerField()
I want to show special link in template for customer if she is allowed to
drink.
class Customer(models.Model):
age = models.IntegerField()
@property
def allowed_to_drink(self):
return self.age >= 18
And in template I can do
{% if customer.allowed_to_drink %}.
But in another view I want to show only those customers, who are allowed to
drink.
So, in view I write
drinkers = [customer for customer in models.Customer.objects.all() if
customer.allowed_to_drink].
But what if I have one million customers? It is insane to check this field
on Python side instead of database side.
I use ORM:
models.Customer.objects.filter(age__gte=18).all()
And DRY principle is now violated.
See, I have knowledge "allowed_to_drink -> (age >= 18) " and I want to
write in once, and then use both in ORM queries and object method.
And I am not alone here:
https://stackoverflow.com/questions/31658793/django-filter-query-on-with-property-fields-automatically-calculated
https://stackoverflow.com/questions/2143438/is-it-possible-to-reference-a-property-using-djangos-queryset-values-list
Here is what I suggest
class Customer(models.Model):
age = models.IntegerField()
allowed_to_drink = models.CalculatedField(Q(age__gte=18))
# Using in ORM
Customer.objects.filter(allowed_to_drink=True)
# It actually converted to
Customer.objects.filter(Q(age__gte=18))
# Using it in code
Customer().allowed_to_drink
# This part a little bit tricky, since you will need to check in on Python
side.
# "age__gte" should be converted to
funcs = {
"gte": lambda instance, field, value: getattr(instance, field) >= value
}
instance_field, func = "age__gte".split("__")
funcs[func](instance, instance_field, 18)
But we already have code to convert Q to SQL, so it should be easy to do it
for python.
Some more ideas:
* "Q" may have lazy evalutation here for cases like
"models.CalculatedField(Q(date__gte=now()))". Could be implemented with
lambdas, or we can simply allow only literal here.
* With Postrges you can even store calculated field in database (it has
calculated column), but it works only for literals.
I think this functionality should be supported by Django core because it
affects admin, forms (calculated fields can't be changed), migrations and
ORM.
*Ilya Kazakevich*
PyCharm developer.
http://www.jetbrains.com
The Drive to Develop
--
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/58aa034b-99de-4bad-98e4-5c200501b777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Suggestion: add default "registration/login.html" to django.contrib.auth
So, should I create a ticket? On Tuesday, March 3, 2015 at 4:05:01 PM UTC+3, Ilya Kazakevich wrote: > > Hello, > > When I use Django auth, I need to provide login.html myself. But Django > encourages applications to have default templates which can be overwritten > by user (via filesystem.Loader, for example). > I suggest to provide default login.html with simple HTML form. User may > always overwrite it. > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/75c442e8-b540-49f5-a924-97a9b138370c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Suggestion: add default "registration/login.html" to django.contrib.auth
I agree: adding template from example is good idea! And I believe it will be used at least by newbies who just study Django auth system and by people who just need prototype. Providing default is better than copy/pasting example from docs. On Tuesday, March 3, 2015 at 5:26:10 PM UTC+3, Marc Tamlyn wrote: > > I can see the merit of including our documented example as an actual > template as a starting point. It's unlikely to be used exactly as is very > often but it reduces getting started friction for some users - "huh this > view doesn't work, better go read the docs" > > I'd perhaps be inclined to include it without styles even. > > Marc > > On 3 March 2015 at 14:22, Ilya Kazakevich <kazakev...@gmail.com > > wrote: > >> I do not think admin templates should used. But something very simple and >> dumb (that looks similar to browser HTTP auth window). Here is example: >> http://pastebin.com/nnX36RB6 >> Css should be moved to static files, of course, to make this template >> cleaner and slightly more customizable. >> >> Imagine I need to create working solution as fast as I can. I really do >> not care about good UI now, because I need only a prototype to show it to >> my customer. I will not spent time creating nice login page: I just simply >> copy/paste template from Django documentation. And login page from contrib >> is great aid here. I will probably change login page UI later, but it is >> minor issue and priority is low. Many people in Intranet solutions >> (portals, CRMs and so on) are happy with browser HTTP auth window. They >> really do not care about how ugly is it. >> >> >> >> >> On Tuesday, March 3, 2015 at 4:36:52 PM UTC+3, Tim Graham wrote: >>> >>> The admin templates extend "admin/base_site.html" and rely on the >>> presence of specific template blocks so I don't think it's appropriate for >>> those dependencies to be added to contrib.auth. I'm curious to see what >>> content you would propose for a default template. Typically I've seen login >>> templates that extend from a project's base template so it inherits all the >>> project specific styles, JavaScript, etc. I'm not sure a default template >>> would actually be used much in practice. >>> >>> On Tuesday, March 3, 2015 at 8:18:39 AM UTC-5, Tino de Bruijn wrote: >>>> >>>> Yeah, or default to admin/login.html. The admin ships with all >>>> necessary "registration" templates, but for some reason only the >>>> login.html >>>> is included in the admin directory. >>>> >>>> On Tue, Mar 3, 2015 at 2:05 PM, Ilya Kazakevich <kazakev...@gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> When I use Django auth, I need to provide login.html myself. But >>>>> Django encourages applications to have default templates which can be >>>>> overwritten by user (via filesystem.Loader, for example). >>>>> I suggest to provide default login.html with simple HTML form. User >>>>> may always overwrite it. >>>>> >>>>> -- >>>>> 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-develop...@googlegroups.com. >>>>> To post to this group, send email to django-d...@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/django-developers. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/django-developers/9487d6c7-8ee2-4a64-aae6- >>>>> 9a05574c1464%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/django-developers/9487d6c7-8ee2-4a64-aae6-9a05574c1464%40googlegroups.com?utm_medium=email_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >> 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-develop...@googlegroups.com . >> To post to this group, send email to django-d...@googlegroups.com >> . >> Visit this group at http://groups.google.
Re: Suggestion: add default "registration/login.html" to django.contrib.auth
I do not think admin templates should used. But something very simple and dumb (that looks similar to browser HTTP auth window). Here is example: http://pastebin.com/nnX36RB6 Css should be moved to static files, of course, to make this template cleaner and slightly more customizable. Imagine I need to create working solution as fast as I can. I really do not care about good UI now, because I need only a prototype to show it to my customer. I will not spent time creating nice login page: I just simply copy/paste template from Django documentation. And login page from contrib is great aid here. I will probably change login page UI later, but it is minor issue and priority is low. Many people in Intranet solutions (portals, CRMs and so on) are happy with browser HTTP auth window. They really do not care about how ugly is it. On Tuesday, March 3, 2015 at 4:36:52 PM UTC+3, Tim Graham wrote: > > The admin templates extend "admin/base_site.html" and rely on the presence > of specific template blocks so I don't think it's appropriate for those > dependencies to be added to contrib.auth. I'm curious to see what content > you would propose for a default template. Typically I've seen login > templates that extend from a project's base template so it inherits all the > project specific styles, JavaScript, etc. I'm not sure a default template > would actually be used much in practice. > > On Tuesday, March 3, 2015 at 8:18:39 AM UTC-5, Tino de Bruijn wrote: >> >> Yeah, or default to admin/login.html. The admin ships with all necessary >> "registration" templates, but for some reason only the login.html is >> included in the admin directory. >> >> On Tue, Mar 3, 2015 at 2:05 PM, Ilya Kazakevich <kazakev...@gmail.com> >> wrote: >> >>> Hello, >>> >>> When I use Django auth, I need to provide login.html myself. But Django >>> encourages applications to have default templates which can be overwritten >>> by user (via filesystem.Loader, for example). >>> I suggest to provide default login.html with simple HTML form. User may >>> always overwrite it. >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/9487d6c7-8ee2-4a64-aae6-9a05574c1464%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/9487d6c7-8ee2-4a64-aae6-9a05574c1464%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aae4454c-7823-41cc-aaf2-914eb7b7c95f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Suggestion: add default "registration/login.html" to django.contrib.auth
Hello, When I use Django auth, I need to provide login.html myself. But Django encourages applications to have default templates which can be overwritten by user (via filesystem.Loader, for example). I suggest to provide default login.html with simple HTML form. User may always overwrite it. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9487d6c7-8ee2-4a64-aae6-9a05574c1464%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
"stable API" misconception giving BaseManager and Manager as examples
Hello,
In Djnago 1.7 Manager class extends BaseManager (actually, it extends its
proxy, created using from_queryset). BaseManager is not mentioned in
official documentation, so it is not part of official ("stable") api, right?
"All the public APIs (everything in this documentation) " (from here
https://docs.djangoproject.com/en/dev/misc/api-stability/)
But it does not start with underscore and its module
(django.db.models.manager) is public module aswell. So, it should be
considered as public class according to python codestyle.
I believe this fact confuses user. May one use BaseManager or minor api
change may brake such usage?
The other problem is there is no official Manager reference: there is a
good manual, but no reference where all methods are listed (like we have
for QuerySet, for example).
So, what is the official, stable Manager API? Most developers know answer
to this question intuitively, but there is no formal way to answer it,
right?
I believe that in Ideal Project there should be something like this:
1) Move all "non public" classes to "_non_public" packages (or make classes
_NonPublic)
2) For each public class list all members in doc or directly in python
documentation.
What do you think?
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2353707c-f7a0-4160-8ef5-c4f918d13383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
