Re: 1.8 release planning

I didn't mean to imply jumping from 1.4 - 1.8 and then fixing all the issues would be the best way forward. I was thinking along the lines of a one page common upgrade issues that summarised the back-compat changes from the previous releases, separated under each release header. Anyways, this i

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. Migrations

Re: Built-in support for Jinja2 in Django

Nice! I've thought about trying to tackle this myself, but never got past the thinking stage. Thanks for taking this on Aymeric. I've got a couple of technical/design questions. > I’ve been thinking about providing built-in support for Jinja2 in Django. I found that supporting pluggable templat

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 app-

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 simply

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 o

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 se

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, an

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 T

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 tests

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 simply

Re: Changes to database-to-python conversions

I'm a big fan of the resolve_columns and convert_values cleanup. The large swaths of removed code in GIS is also very welcome. Great stuff! I suspect I'll be able to make a few improvements in the aggregation/annotation patch I've been working on once this lands. -- You received this message b

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 th

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

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: 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 be

Re: Requiring GitHub login for actions on Trac

her 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. >> >> > TL;DR Identity

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 2

Re: Fields terminology for official Options API

I was thinking "column" fields would make sense but it clashes with the internal concept of columns (Col types), and is only name-appropriate for a database backend. I'm not sure these are actually problems worth considering though. On Friday, 1 August 2014 01:07:21 UTC+10, Collin Anderson wrot

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: [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 t

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: 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 11:20:28

Re: Building a library of SQL functions into Django

> Loic > > > On Monday, 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 wrote: >> >>> On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wr

Re: Building a library of SQL functions into Django

riäinen wrote: > > 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 t

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 t

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 there

Re: Building a library of SQL functions into Django

rote: > > 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): >>self.

Re: Changes to ORM expressions API

code, ability to use Sum('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 impleme

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 part

Re: Building a library of SQL functions into Django

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

Re: Building a library of SQL functions into Django

ld at least provide 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 > > wrote: > >> On Wednesday, June 18, 2014 4:52:11 AM UTC+3,

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 j

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 review

Re: Support for function application in ORDER BY

iscussion on the ML so we can address these concerns without it being 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(&#

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 a

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

to abandon 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

Re: Support for function application in ORDER BY

just call asc, by default, on any expressions 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 cod

Re: Support for function application in ORDER BY

special casing in that function which may not translate very 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 Sm

Re: Support for function application in ORDER BY

> > On Mon, Jun 9, 2014 at 7:48 PM, Josh Smeaton > 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 possib

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

> -- > Aymeric. > > > > On 7 juin 2014, at 10:12, Aymeric Augustin > wrote: > > > Hi Josh, > > > > Fixtures don’t receive a lot of attention because they’re hard to > maintain and generally inferior to object generators such as factory_boy. > S

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 the

Re: Support for function application in ORDER BY

> > Could we use 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. > >

Re: Support for function application in ORDER BY

t; Agreed. It's worth noting that we could have a `Desc` operator for awkward > edge cases where __neg__ doesn't work well, and the default implementation > of __neg__ just returns Desc(self). I've not completely considered all the > possible implications here, just throwing t

Re: Support for function application in ORDER BY

t is still somewhat confusing syntax. ~ is mostly used in Q() objects to mean NOT, and could be very confusing. We also run into similar issues 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 ap

Re: Support for function application in ORDER BY

1:09 UTC+1, Tim Martin wrote: >>> >>> Funnily enough, I'd already seen that patch but I hadn't figured out the >>> full significance of it. I attempted to solve #22288 ( >>> https://code.djangoproject.com/ticket/22288), but spotted that your >>>

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 me

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 functionality

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: [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 encountere

Re: [GSOC] Weekly update

ined, and based > 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 UT

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: > https://docs.google.com/document/d/1yp

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 seei

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: [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 vari

Re: Add support for get_or_none?

nd straight away (any > suggestions??) > > Cal > > On Thu, Mar 13, 2014 at 9:34 PM, Josh Smeaton > > > 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,

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 t

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 .ex

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: [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: 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 those

Re: index_together should also have the same convinience as unique_together

UTC+11, Aymeric Augustin wrote: > > On 2 mars 2014, at 02:40, Josh Smeaton > > 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 > "ac

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 aggressive to the people who

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 i

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 ca

Re: Gsoc project idea

The contrib.gis app and the GIS backends definitely need some loving. There are a number of workarounds and hacks present in the GIS app that makes it a lot harder to work on the ORM in general. I'm not sure if improving GIS would be too ambitious for a GSOC project though, and it definitely re

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 read

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: 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 > through

Re: Improving aggregate support (#14030)

puted (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 at 3:06 AM, Josh Smeaton > > >

Re: Improving aggregate support (#14030)

ev 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)

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)

ard" work for GIS is 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 aro

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. Com

Re: Improving aggregate support (#14030)

not this is picked up for 1.7 or 1.8, I'll continue working on the patch and keeping it 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

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" > > wrote: > >> Hey Aymeric, >> >

Re: App-loading reloaded

Hey Aymeric, I've just merged master back into a branch I'm working on, and I'm seeing the following error when trying to run the django test suite: (django)smeatonj ~/Development/repos/django/tests $ PYTHONPATH=..:$PYTHONPATH ./runtests.py Testing against Django installed in '/Users/smeatonj/

Re: Improving aggregate support (#14030)

e(Count(Case(condition=Q(author__birthdate__year__gt=1891), true=1, false=0)) But that's just 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, - Jo

Re: Improving aggregate support (#14030)

any Aggregates need to pollute the > entire tree with that knowledge? > - 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

Re: Improving aggregate support (#14030)

if there's 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 tomor

Re: Improving aggregate support (#14030)

egressions failing, but am working through that now. Tomorrow I should be able to start playing with new functionality and writing new tests. I'll also take a look into running tests on GIS and fixing any errors that rear their heads there. Cheers, - Josh On Thursday, 9 January 2014 00:05:23 UT

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( F('tim

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 receiv

Re: Improving aggregate support (#14030)

ue rather than 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, D

Re: Improving aggregate support (#14030)

ow a straightforward implementation of Aggregates on top. 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

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)

view on whether 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

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 th

<    1   2   3   4