Improving aggregate support (#14030)

I'm interested in tackling ticket#14030, ideally before the Jan 20th cutoff, but I'm looking for some guidance. There have been a lot of references to Anssi Kääriäinen attempting an ORM refactor before trying to fix aggregates, but I'm not sure if

Re: Improving aggregate support (#14030)

it makes it in or not (and my ability of course). Regards, Josh On Sunday, 22 December 2013 22:04:36 UTC+11, Anssi Kääriäinen wrote: > > On Saturday, December 21, 2013 3:15:12 AM UTC+2, Josh Smeaton wrote: >> >> I'm interested in tackling >> ticket#14030<https://co

Re: Improving aggregate support (#14030)

So, after hacking away a little bit yesterday, I came to the same conclusion that Anssi did back when the first PR was sent. Namely, that the ExpressionNode <-> SQLEvaluator structure seems overly complex, and makes it difficult to create custom "ExpressionNodes". To build a custom Expression,

Re: Improving aggregate support (#14030)

. I'll be away until the 2nd of January, but will pick this up again then. Cheers - Josh On Tuesday, 24 December 2013 11:41:19 UTC+11, Josh Smeaton wrote: > > So, after hacking away a little bit yesterday, I came to the same > conclusion that Anssi did back when the first PR w

Re: Improving aggregate support (#14030)

wrapping it in an Evaluator. I'll make a start on refactoring Aggregate to inherit from ExpressionNode regardless. Hopefully that will make clear some uncertainties. Cheers, Josh On Sunday, 29 December 2013 04:15:44 UTC+11, Anssi Kääriäinen wrote: > > On Wednesday, December 25, 2013 5:5

Re: Renaming apps.has_app

+1 on .installed() as it reads quite well. The only thing I have against it is that it may sound like it can take an iterable of app names, where has_app() does not have that problem. app_installed() is more accurate but is longer and less nice to read. My 2 cents. Cheers, Josh -- You

Re: Improving aggregate support (#14030)

An update. I've had some success with refactoring Aggregates as ExpressionNodes. The aggregates test suite is now passing, but I still have some failures with aggregates_regress test suite. The refactoring should allow behaviour like below possible: Model.objects.annotate(total_time=Sum(

Re: Improving aggregate support (#14030)

anything glaringly obvious (to you) that is missing or broken. Regards, - Josh On Thursday, 9 January 2014 00:33:08 UTC+11, Josh Smeaton wrote: > > I'll preface by saying it's late for me, and I'm about to sign off, so any > mistakes below I will correct tomorrow after some sleep. > &

Re: Improving aggregate support (#14030)

- Instead of using is_ordinal and is_computed (confusing name, why not > is_float), you could eliminate those and define output_type for each > Aggregate that does something special. > - What does is_summary mean? > > Regards, > Michael Manfre > > > On Sat, Jan 11, 2014

Re: Improving aggregate support (#14030)

speculation at the moment. More work needs to be done to see what that'd look like in annotations, but then the path is clear for implementing it with order_by and friends. Cheers, - Josh On Sunday, 12 January 2014 19:11:11 UTC+11, Anssi Kääriäinen wrote: > > On Saturday, January 11, 2014 10:06:14

Re: App-loading reloaded

Perfect, that did the trick, thanks - Josh On Tuesday, 14 January 2014 00:25:38 UTC+11, Michael Manfre wrote: > > Git clean -fdx > > I had the same problem the other day. > On Jan 13, 2014 7:51 AM, "Josh Smeaton" <josh.s...@gmail.com > > wrote: > >>

Re: Improving aggregate support (#14030)

t up to date with master so it doesn't go stale. That's happened enough times :P Cheers - Josh On Sunday, 12 January 2014 21:28:33 UTC+11, Anssi Kääriäinen wrote: > > On Sunday, January 12, 2014 10:52:03 AM UTC+2, Josh Smeaton wrote: >> >> Any idea how to do this? >>> >

Re: Improving aggregate support (#14030)

Vendor specific SQL is now possible, and uses the monkey patching described above. I worked around the problem of temporarily changing the template, by putting the template and the function into the extra dict on init. Any modifications made to the dict are then made for that instance only.

Re: Improving aggregate support (#14030)

changing the models/query and models/sql/query as I've done for core. Cheers, - Josh On Tuesday, 14 January 2014 17:56:29 UTC+11, Josh Smeaton wrote: > > Vendor specific SQL is now possible, and uses the monkey patching > described above. I worked around the problem of tempora

Re: Improving aggregate support (#14030)

Quick update. GIS support is nearly done, I just have two failing tests to take care of (one to do with lookups setting srid, and another that is producing the wrong value). I have a few validation checks to make inside prepare, and then it's on to writing tests that make use of aggregates and

Re: Improving aggregate support (#14030)

o-dev IRC channel is a good > place to ask those questions. It is often easier to solve design issues > real-time than on a mailing list. > > - Anssi > >> On Wednesday, January 15, 2014 3:57:33 PM UTC+2, Josh Smeaton wrote: >> Quick update. GIS support is nearly done,

Re: Improving aggregate support (#14030)

y not > is_float), you could eliminate those and define output_type for each > Aggregate that does something special. > - What does is_summary mean? > > Regards, > Michael Manfre > > > On Sat, Jan 11, 2014 at 3:06 AM, Josh Smeaton > <josh.s...@gmail.com &

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

Sorry to jump in here, please ignore me if I make no sense. Allowing one more release before AUTH_PROFILE_MODULE is removed would allow > him to use the new migration system to create a custom migration to migrate > away from using the profiles. Otherwise, he'd need to use South or go >

Re: GSoC query

I've been working on aggregation lately, and have opened up a PR https://github.com/django/django/pull/2184 I think the implementation is promising, but it hasn't been vetted by a core contributor yet. I've also begun work on https://github.com/jarshwah/django/commits/nonaggregate-annotations,

Re: [GSOC] Improving the Test-Suite

Just a few observations that I've had when running the test suite that may be relevant. - There are lots and lots of different test modules that may be relevant to a particular change, and some may not seem relevant until you run the entire suite - bug* modules are hard to classify without

Re: GSOC 2014 Project Proposal

Would increasing the scope of the django tutorial itself and deprecating the djangobook solve the issue of new users learning django? - The tutorial does a really great job of introducing the basics. - Online resources for learning django have improved, significantly, since 0.96. Although it

Re: GSoC Project Idea

As I mentioned in the last thread, I've already made some progress on improving aggregates and annotations. I've submitted this PR for review https://github.com/django/django/pull/2184 and discussion here: https://groups.google.com/forum/#!topic/django-developers/8vEAwSwJGMc Again, I'm unsure

Re: index_together should also have the same convinience as unique_together

On Sunday, 2 March 2014 03:56:13 UTC+11, Aymeric Augustin wrote: > > On 1 mars 2014, at 13:16, Christian Schmitt > > wrote: > > > I mean some pull requests are open since two years. Why don’t you close > them, when they won’t apply anymore? > > Because it feels

Re: index_together should also have the same convinience as unique_together

1, Aymeric Augustin wrote: > > On 2 mars 2014, at 02:40, Josh Smeaton <josh.s...@gmail.com > > wrote: > > > At the very least it might be a good middle ground to tag PRs with > "Requires Work" or "Not Ready", so they can be easily filtered out from

Re: Testing parameters in database settings

Mentioned on the PR already, but writing some thoughts here too. I like the change. Moving test settings into their own sub-dict makes a lot of sense. Missing are settings for creating the datafile and datafile size for Oracle though. I'm unsure if a separate patch should be submitted for

Re: [GSoC 2014 Proposal] Improving Error and Fixing up related issues.

Just a brief comment. Perhaps it'd be useful to link to the appropriate trac tickets in your proposal. Regards, Josh On Saturday, 8 March 2014 15:59:27 UTC+11, anubhav joshi wrote: > > Hi all, >My previous thread: > https://groups.google.com/forum/#!topic/django-developers/PDY8EEYaHao

Re: [GSoC 2014 Proposal] Improving Error and Fixing up related issues.

Yes, people can look elsewhere for the tickets, but it'd probably have more *impact* if the tickets were referenced directly in the proposal. That way, someone can dive into the deeper discussion for a particular bug (by reading the comments on the ticket). The idea is that you don't want your

Re: Re-open #7231: New "join" parameter for the "extra" QuerySet method

My take on this is that .extra and .raw are 'hacks' that only exist because the existing functions of the ORM are too limited. There are a few changes coming to extend the utility of .annotate (and .aggregate), along with the Lookup and Transform APIs, that should solve 90% of use cases that

Re: Add support for get_or_none?

+1 on get_or_none. It seems to be a pattern that comes up quite a lot in user code, and I know I've had use for it lots of times. Cal, are you thinking of having a loose function get_or_none(qs, args, kwargs), or implementing it directly on the manager? I think it'd make sense to implement on

Re: Add support for get_or_none?

ggestions??) > > Cal > > On Thu, Mar 13, 2014 at 9:34 PM, Josh Smeaton > <josh.s...@gmail.com > > wrote: > >> +1 on get_or_none. It seems to be a pattern that comes up quite a lot in >> user code, and I know I've had use for it lots of times. Cal, are yo

Re: [GSOC] Introduction and task proposal

If you haven't already got all your databases installed on your development machine, I *highly* recommend checking out https://github.com/jphalip/djangocore-box. It's a vagrant VM environment that already has MySQL, PostgreSQL, and SQLite installed (plus most GIS installations), along with

Re: Improving aggregate support (#14030)

Code complete: https://github.com/django/django/pull/2496 - Aggregates have learnt arithmetic and how to interact with F() expressions - Annotations can now accept non-aggregate expressions I'm in the process of writing documentation, some of which I've committed and is available within the PR.

Re: Revisiting multiline tags

And for the last month or so a patch has existed and feedback has been requested. Performance was one of the concerns mentioned, so download Curtis' patch, and test that it works for your use case. He has asked for feedback a number of times. Unless you try it out, I fear that you won't be

Re: [GSOC] Weekly update

Best of luck! On Tuesday, 20 May 2014 03:56:06 UTC+10, Daniel Pyrathon wrote: > > Hi All, > > Today I will be starting my weekly updates on my SoC project: refactoring > Meta to a stable API. For anyone who missed out, you will be able to view > it here: >

Re: [GSOC] Weekly update

; on one very interesting suggestion on IRC, I will try to see how my API > syntax looks in modelforms.py. > > As said previously, and feedback is greatly appreciated. > > Hi from Pycon IT! > > Daniel Pyrathon > > On Tuesday, May 20, 2014 3:25:45 PM UTC+2, Josh Smeaton wr

Re: [cx-oracle-users] cx_Oracle 5.1.3

Thanks for pointing this out - I was just about to start a new project with oracle 12c and python 3.4, both of which are only now supported. Great timing! On Sunday, 25 May 2014 16:20:21 UTC+10, Shai Berger wrote: > > Hi all, > > This release of cx_Oracle includes fixes the segfaults

Re: Support for function application in ORDER BY

I would like to point you towards a patch I'm currently working on which is essentially your option 2: https://github.com/django/django/pull/2496 It doesn't seem very relevant at first, since it only applies to .annotate and .aggregate, but the infrastructure behind it certainly does. In short,

Re: FormWizard needs confirmation step logic. ticket #21644

If formtools were to be pulled out and released separately, would that theoretically mean that releases could come more frequently than django core (provided there was community interest and maintenance)? I think that would be a decent carrot for community members that rely on its

Loading fixtures once for each TestCase to improve running time

I've been looking into the django testing infrastructure today to see if there was any particular reason why the test suite takes so long to run. Mainly, I didn't understand why fixtures are loaded for every single test method. To be honest, I didn't think fixtures were loaded for every test

Re: Support for function application in ORDER BY

/ticket/22288), but spotted that your >>> patch would possibly solve the problem entirely, and at the very least >>> breaks my attempt to solve that specific case. >>> >>> The expression concept seems like a good direction to be going in. I'd >>> defini

Re: Support for function application in ORDER BY

ssues with the `order_by( F()+F() )` use case above - applying a unary operator to either of those objects won't actually result in any ordering being applied. Josh On Monday, 9 June 2014 02:07:42 UTC+10, Tim Martin wrote: > > > On Sunday, 8 June 2014 13:24:01 UTC+1, Josh Smeaton wrote:

Re: Support for function application in ORDER BY

> of __neg__ just returns Desc(self). I've not completely considered all the > possible implications here, just throwing the idea around. > > > On 9 June 2014 01:53, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> > That sounds like a workable approach. If I'm

Re: Support for function application in ORDER BY

just F() for this, that is the examples would be: > -F(F('field')+F('other')) > F(F('field')+5, output_type=IntegerField()) > > As Marc said in another post plain parentheses should be enough for the > first case. > > - Anssi > > On 06/09/2014 01:19 PM, Jos

Re: Support for function application in ORDER BY

> However, I think having some special case code in filter(), annotate() and anything else that takes expressions would be OK I strongly disagree with this. Expressions are context insensitive at the moment, which means they can be used anywhere. If we start externalising behaviour based on

Re: Loading fixtures once for each TestCase to improve running time

t; Still, it would be good to optimize them. > > > > On 7 juin 2014, at 09:34, Josh Smeaton <josh.s...@gmail.com > > wrote: > > > >> I've been looking into the django testing infrastructure today to see > if there was any particular reason why the test

Re: Support for function application in ORDER BY

un 9, 2014 at 7:48 PM, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> - should expressions in order_by support random ordering (?) ? I don't >> think so, but I haven't ever had a need for random ordering so I'm not sure. >> > > It should be possible to crea

Re: Support for function application in ORDER BY

y well. The cleanup here could be incremental though, so I wouldn't worry too much about it right yet. Cheers On Wednesday, 11 June 2014 04:47:46 UTC+10, Tim Martin wrote: > > On Tuesday, 10 June 2014 00:48:14 UTC+1, Josh Smeaton wrote: >> >> > However, I think having some

Re: Support for function application in ORDER BY

passed in. Think you've come up with a winner here. Cheers, On Wednesday, 11 June 2014 20:58:04 UTC+10, Shai Berger wrote: > > On Tuesday 10 June 2014 02:48:14 Josh Smeaton wrote: > > > However, I think having some special case code in filter(), annotate() > > > > and any

Re: Loading fixtures once for each TestCase to improve running time

this patch and ticket myself - mainly due to the sqlite threading issues. If someone else would like to run with it, I'll be happy to share any information I have. - Josh On Wednesday, 11 June 2014 09:34:14 UTC+10, Josh Smeaton wrote: > > I used the patch in the above ticket as

Re: Time to drop support for Oracle < 11?

Personally we use oracle 11g (with a plan to move to 12c within the next year), but it wasn't that long ago that we were still using 10g. We're a smaller company that is able to upgrade our database without significant impact, but I'm betting (and guessing..) the vast majority of oracle users

Re: Support for function application in ORDER BY

hidden inside this thread? Josh On Monday, 16 June 2014 03:45:02 UTC+10, Tim Martin wrote: > > On Wednesday, 11 June 2014 12:28:20 UTC+1, Josh Smeaton wrote: >> >> > Model.objects.filter(...).order_by( F('fld_a').desc(), >> F('fld_b')).asc() ) >> > Model.obj

Re: Ready for checkin

I see what you're saying Daniele, I had to ask about the terminology only a couple of weeks ago. Hopefully I can provide some clarity. Ready For Check-in means that someone other than the author has reviewed the patch and believes it is ready to be merged. However, the patch must also be

Building a library of SQL functions into Django

Over the last 6 months we've been working on a fairly large refactor to expressions. As a brief catch up, expressions are currently F() expressions. I've expanded their scope to include Aggregates. As a by-product of this we can now use any kind of expressions in the .annotate() function, not

Re: Building a library of SQL functions into Django

vide a common pattern for people to do so, and > hopefully make the whole process more manageable and predictable. > > -- > Curtis > > > > On 18 June 2014 17:09, Anssi Kääriäinen <anssi.ka...@thl.fi > > wrote: > >> On Wednesday, June 18, 2014 4:52:11 AM

Re: Building a library of SQL functions into Django

n Wednesday, 18 June 2014 23:31:39 UTC+10, Aymeric Augustin wrote: > > 2014-06-18 15:19 GMT+02:00 Josh Smeaton <josh.s...@gmail.com > >: > >> At the moment the API sanctions monkey patching by providing the >> as_vendor() method >> > > Yes, I'm not

Re: Building a library of SQL functions into Django

Hi All, I think there may be some confusion here since I didn't actually explain myself properly to begin with. Let's run through an example: class Lower(Func): function = 'LOWER' This function will work for all core backends, but it will also work for all third party backends. Third

Re: Changes to ORM expressions API

('foo') > + Sum('bar') style aggregations, and the ability to write new expressions > and aggregates using a public stable API. > > A patch exists that implements the new way. It is written by Josh Smeaton. > The patch also implements a way to annotate non-aggregates to queri

Re: Building a library of SQL functions into Django

ix.com> wrote: > > Hi, > > A minor style point: > > On Thursday 19 June 2014 02:56:10 Josh Smeaton wrote: >> >> class Lower(Func): >>function = 'LOWER' >> >> [...] >> >> def mongo_lower(self, compiler, connection): >>

Re: Building a library of SQL functions into Django

I agree that 3rd party backends should have a hook to provide their own customisations. I still think that the as_vendor approach is useful provided that the backend has a chance to register their customisations (where required - they still automatically use the default as_sql() method if

Re: Building a library of SQL functions into Django

> If this is going to be moved off SQLCompiler, I think DatabaseOperations is a better place for it because we already have DatabaseOperatoins.combine_expression. The compile method will need access to the compiler to match the signature of as_sql (and it is necessary in some cases to inspect

Re: Building a library of SQL functions into Django

ote: > > On Mon, 2014-06-30 at 10:48 +0300, Josh Smeaton wrote: > > > So what kind of hook are we looking at here? Supplying a different > > `.compile()` method that gets the node passed in? Won't that lead to > > all kinds of isinstance checks to see if the compile

Re: Building a library of SQL functions into Django

onday, June 30, 2014 7:08:38 PM UTC+7, Marc Tamlyn wrote: >> >> FWIW I agree with Anssi >> >> Marc >> >> >> On 30 June 2014 12:00, Anssi Kääriäinen <anssi.ka...@thl.fi> wrote: >> >>> On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wrote:

Re: Support byte range requests in django.views.static.serve

I'm actually +1 on the idea (I haven't looked at the patch). I use django-downloadview for streaming files which has support for the built in django server in development but testing that skipping/range works is impossible without deploying to a real web server. On Tuesday, 1 July 2014

Re: Building a library of SQL functions into Django

Thanks for the input here - I didn't think there'd be such an aversion to directly monkey patching the function objects, but there clearly is from backend maintainers and core developers. So time to move past that and come up with something that's acceptable. The solution Anssi presented above

Re: [GSOC] Weekly update

Excellent work, well done. I have a couple of questions/ideas though. 1. The use of bit flags irks me. Would it be possible just to use numerous keyword arguments to the new get_fields ? 2. Since you've reduced the API to effectively two functions (get_fields, get_field), is it still necessary

Re: Removing formtools from contrib (and call for maintainers)

I think the "blessed packages" idea is a good one - especially if it entails inclusion into the build/test system. At the moment it is very difficult to know if any changes that are made will affect third party libraries unless you have an extremely good grasp of an entire sub-system (ORM, I'm

Re: Requiring GitHub login for actions on Trac

In that case, is it easy enough to support github oauth + the current trac auth concurrently? If a user chooses to go through the harder path, that's fine. I like the idea of using github oauth. Password managers usually have a miserable time supporting HTTP basic auth. On Thursday, 7 August

Re: Requiring GitHub login for actions on Trac

sed for Trac (among may other uses) >> >> We already have that: https://www.djangoproject.com/~aaugustin/ >> >> > and could later be linked to any OAuth providers, including but not >> limited >> > to GitHub. >> >> We don’t have that. >

Re: ORM Optimization for filtering by related existence

I think the idea is good, but the implementation you have here isn't desirable. Maybe you could experiment with writing your own custom lookup (https://docs.djangoproject.com/en/dev/howto/custom-lookups/) and see if it fits into the framework that way. AFAIK, anything requiring .extra should

Re: ORM Optimization for filtering by related existence

Just to be clear, are you (Curtis) suggesting that the isnull lookup should do an EXISTS when looking at a join? I don't think that's a very good idea - having that construct can be extremely useful. I think adding an __exists lookup to relationships would be a great addition - but that's where

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

+1 - useful for user code that guards against accidental poor ORM usage. On Monday, 18 August 2014 05:47:15 UTC+10, jdunck wrote: > > I use this method on my own test subclasses, and I find it useful as a > tripwire: a cause for review and consideration, more than a hard error. Did > the number

Specifying the SERVICE_NAME for Oracle DB connections

Oracle has two concepts of database names - the SID or the SERVICE NAME. I'll gloss over the details, but the SID is the database instance, and the SERVICE NAME is an alias to an instance or cluster. Currently the database['NAME'] entry represents the SID unless HOST and PORT are empty, then

Re: integrating django-secure

-1 on using dictionaries to group somewhat related settings. Dicts make it much harder to override specific keys - and implementing a dict merge to get around a problem that we're creating ourselves for reasons of perceived attractiveness seems a little backwards. Mergingi If I want to

Re: @load_fixture annotation for test cases.

The idea isn't bad, except that the performance of fixture loading is pretty terrible in general. Take a look at ticket https://code.djangoproject.com/ticket/20392 for some performance profiling and discussion. As far as I'm concerned, using fixtures is the wrong way to populate data for

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

I really like this idea, and have wanted something similar every time I start a new project and begin building out the main template. I think including this (or something like this) in core is a great idea. Just because it *can* be implemented in 3rd party code, doesn't mean it has to be. On

Re: Bug in django\forms\models.py in _construct_form, line 593?

At this point I think you're in the realm of django-users. This is probably a bug in user code rather than django, and you'll get better help from the django-users mailing list or IRC. At a guess the issue may be related to your views not being threadsafe, so you should show your entire view,

Re: Two proposals for the Django Code of Conduct.

(I found I've said "correct me if I'm wrong" in nearly every paragraph I've written - so please, correct anything below that you don't agree with) I've been wanting to stay out of this conversation because, as Aymeric put it, it is a very sensitive topic. But I've got a few things to say. It

Re: Two proposals for the Django Code of Conduct.

Ben, I know you haven't advocated the removal of the CoC (or #84 for that matter), but you've questioned speech and behaviour limitations upthread, so I thought I would include my thougths of a CoC in general. Just because the code of conduct hasn't been used for intervention (forgetting the

Re: Two proposals for the Django Code of Conduct.

Kevin, > It simply says, in deliberately vague language, that if a member of the Django community is treated abusively by another member of the Django community _outside_ a Django forum and that abuse is reported to the conduct committee, the committee will not reject the report outright

Re: Migration challenges

I have some comments regarding 3. The idea, if I've understood your recount of the problem, is a good one. You want to be able to run a backwards-compatible migration (database works with app-state X and X+1), upgrade your application servers, and then run another migration that works with

Re: 1.8 release planning

I was wondering when this discussion was going to happen - it's good to see some dates finally proposed, thanks Tim. The LTS proposal is a good one. It should give people enough time (6 months) to jump to the next LTS release. I also think that 1.8 should be a good candidate for LTS.

Re: Building a library of SQL functions into Django

This discussion got a little off track, and I'd like to bring it back to the original purpose. Which SQL functions should we implement when the aggregate/annotation refactor lands? I'll take the output of this discussion and create a ticket in trac once we've at least got a start on a minimal

Re: Building a library of SQL functions into Django

I've opened the ticket https://code.djangoproject.com/ticket/23753 to track which functions should be implemented. -- 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

Re: Creating data in TestCase.setUpClass() (proposed refactoring)

Just a quick FYI - https://groups.google.com/forum/#!msg/django-developers/N0HEAD1ht8k/GQJ77RLUydsJ I tried to implement fixture loading in setupClass() and ran into a few difficulties. I did a lot of profiling though. You get about a factor of 3 speedup for tests that use fixtures. It only

Re: Admin bug that causes data loss need attention

I don't think a doc patch is sufficient to address the problem, and I highly doubt that a warning would be heard by the vast majority. The attention this bug needs is someone to write a patch to fix the code. Looking at the ticket, 4 weeks ago someone suggested some code that *may* fix the

Re: A case for CASE expressions and bulk_update

Hi Michael, Great to see new expressions being used already! Speaking specifically about the Case structure, I think it looks nice. I was planning on writing a few functions (https://code.djangoproject.com/ticket/23753) which included Case/When of some description. My idea of a Case API was:

Should annotations allow model field constraints?

Trac user jbg has found a regression with the aggregation/annotation refactor #14030. The crux of the problem comes down to whether annotations and aggregations should respect constraints on model fields. The specific example raised is as follows: Model.objects.aggregate(

Re: Should annotations allow model field constraints?

Thanks for all the comments. I'll address the relevant bits below. > So, if the user explicitly asks for max_digits=3 in the output_field > argument, then we should enforce that. Or, alternatively we should > disallow setting max_digits for explicit output_field in expressions. > I don't

Re: Should annotations allow model field constraints?

I've marked the patch as ready for checkin. Instantiating fields without any arguments for decimal field is now supported by all backends. The format_number function has learnt to understand max_digits or decimal_places being None. The format_number function needs review though. When

Re: Feature request: delegate more password related operations to auth backends (#23896)

I've been maintaining a custom django backend for quite awhile now. It delegates authentication and authorization to an internal API. I do not use a custom User model at all. The backend completely handles the reset/change password logic, and the form uses the methods on the backend directly.

Re: Feature request: delegate more password related operations to auth backends (#23896)

https://gist.github.com/jarshwah/c5b9abebb452f2e3286f I've removed some of the error handling and custom application bits, and I've also renamed the classes. But this is the meat of auth for my project. You'll notice that the backend is hardcoded in the constructor, because we only use this

Re: Feature request: delegate more password related operations to auth backends (#23896)

Correct - I've updated the gist: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f -- 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,

Re: Feature request: delegate more password related operations to auth backends (#23896)

Ok, I see where your suggestions could make a lot of sense. Thanks for persisting with me. I've updated my gist again with what a refactor could allow it to look like: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f The backend remains unchanged. The form removes most custom handling,

Re: A case for CASE expressions and bulk_update

Hi Michal, I'm about ready to implement Case/When expressions, do you mind if I use your implementation? Also, do you think it's necessary or desirable to have a SimpleCase and a Case? Josh On Wednesday, 19 November 2014 08:34:10 UTC+11, Michał Modzelewski wrote: > > I've put my code up on

Re: A case for CASE expressions and bulk_update

On Tuesday, 16 December 2014 18:23:29 UTC+11, Michał Modzelewski wrote: > > Sure. I was planning to work on it myself, but wanted to discuss API, > passing in output_fields, and casting results first. > I started with 2 classes because I only needed SimpleCase first to > implement the

Re: annotate() and generic relations

I admit I don't fully understand how generic relations work (I try not to use them in my projects), but I would think we should be able to make annotations work properly with them. Now that aggregates are based internally on F() objects, we should be able to special case F() for generic

Re: A case for CASE expressions and bulk_update

+11, Tim Graham wrote: > > Unlike in previous release cycles, we are going to try a complete feature > freeze at alpha. The details are outlined here: > > https://code.djangoproject.com/wiki/Version1.8Roadmap > > On Tuesday, December 16, 2014 8:01:23 PM UTC-5, Josh Smeaton wr

Re: Easier to use natural keys.

Would you mind linking to the ticket you're talking about? Will encourage more people to participate if they don't have to search Trac for it ;) Josh On Monday, 22 December 2014 01:05:14 UTC+11, Brian Faherty wrote: > > Hey Folks, > Teams I have been on in the past have used natural keys

Re: Easier to use natural keys.

So he did, Flux must have killed link colours for me. Sorry folks! On Monday, 22 December 2014 10:50:22 UTC+11, Russell Keith-Magee wrote: > > > On Sun, Dec 21, 2014 at 10:33 PM, Josh Smeaton <josh.s...@gmail.com > > wrote: >> >> Would you mind linking to t

Re: Support for function application in ORDER BY

then. I'm happy to pick up your work and finish it off if you haven't got the time to do it though. Just thought I'd give you the chance since you've put in the effort. Josh On Wednesday, 18 June 2014 07:51:31 UTC+10, Tim Martin wrote: > > On Monday, 16 June 2014 01:25:45 UTC+1, Josh Smeaton

  1   2   3   4   >