On Wed, Apr 1, 2009 at 12:31 PM, Max Veytsman <[email protected]> wrote:
Hi Maxim,
> There was a project idea in the wiki called "Improve Query Expressions
> (F() syntax."
>
> Improvements to Handling of Dates
> ==================================
>
> 1) Syntax for comparisons using fields derived from DateField
>
> For instance to select all of the items that were written before the
> 10th of the month I would do
>
> Item.objects.filter(datetime_posted__day__lt=10)
I'm not sure this is the best approach. It isn't consistent with any
other filter operator in Django - for all other operators, the last
part (__lt in this case) is the operator, and all other parts are
considered to be fields that need to be joined.
My preferred approach here would be to allow for annotations that are
non-aggregates. This way, you would annotate the 'day' onto the item
instances, then filter on that annotation:
Item.objects.annotate(posted_day=Day('datetime_posted')).filter(posted_day__lt=10)
This has the added advantage that it allows for user-specified
annotations functions.
> 2) Allow F expressions to access fields derived from DateField.
>
> I.E. for all Items written by an author during his/her birthmonth:
> Item.objects.filter(datetime_posted__month=F
> ('author__birthdate__month')
Again, this should be handled in a way similar to (1). Coming up with
a clean syntax for the RHS of this expression could be interesting,
however.
> 3) Add the __date lookup to DateTimeFields
> I.E. for all Items written on the author's birthday
> Item.objects.filter(date_poststed__date=F(author__birthday))
>
> This is to compare a DateTimeField with a DateField
> This is covered by the following ticket:
> http://code.djangoproject.com/ticket/9596http://code.djangoproject.com/ticket/9596
> which provides a patch, although it may not work for all backends. I
> will make sure it does, and provide more rigorous testing.
+1. This isn't strictly related to F() expressions - it's just another
filter clause - but it is one worth having.
> 4) Allow for annotation by fields derived from F expressions
> This will probably be the meat of the project.
> I.E. to group Items by date:
> Item.objects.annotate(date=F('datetime__date')).values('date').values
> (num_items=Count('id'))
>
> This is covered in ticket #10302(http://code.djangoproject.com/ticket/
> 10302)
This isn't what #10302 is describing. #10302 is describing the ability
to force a GROUP BY on a computed field. Again, once you solve the
annotation of computed fields problem, this becomes relatively
trivial.
> 5) This already has a patch but I think I should mention it. Ticket
> 10514(http://code.djangoproject.com/ticket/10154) allows for
> timedeltas to be added or subtracted from F expressions.
There is a patch, but I'm not sure I'm 100% happy with it. I'm
slightly uncomfortable introducing a completely separate expression
node for dates. The implication is that every new data type will
require its own Node subclass - so String handling, for example, will
require a new node type; any geometry handling will require its own
node type, and so on. I'd rather see a generic approach extend the
base Node definition to carry the extra logic required to support
non-numeric expressions.
> Improvements to Handling of Strings
> ===================================
>
> I also want to allow for string F expressions.
> I'm going to stop using the example for these as they are simpler.
>
> If the field foo contains a string
> 1) F('foo')+"bar" should concatenate the two strings
>
> 2) F('foo')*N should repeat N times
>
> 3) I would like some feedback on this one: would allowing for splicing
> be a good idea?
Meh. I can't say this is a big one for me, but turning Python slicing
syntax into the underlying SQL would be a neat trick.
My bigger concern is F('foo') + F('bar'). This is possibly implied by
(1), but it's worth saying explicitly. However, once you've solved the
'generic expression node' problem, this shouldn't be too hard.
> That's pretty much what I want to do over the summer. I hope that in
> sum this is substantial enough for a GSOC project. I would also love
> for any other recommendations, and for ways to improve the timedelta
> functionality.
The ideas you are presenting here (once you modify the xx__day to
Day('xx') issues) aren't controversial, and they would be good
additions to Django. From a purely idea point of view, this is all
win.
What is missing from this proposal is any indication that you have
given any thought to these problems beyond "Hey, that ticket looks
cool". Have you made estimates of how long each of these tasks will
take? How did you arrive at those estimates? What makes you think that
your estimates are correct? What complexities do you expect to find?
How do you plan to mitigate problems when they arise?
Remember - we know nothing about you. The ideas you have proposed are
mostly from Django's own Trac instance and wiki, so we haven't learned
a lot about you from the ideas you propose (other than your taste in
problems). Why should we trust you with a GSoC slot?
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
