I originally wanted to work on aggregates/annotation improvement in GSoC
and still wish the same. The issues that I want to consider are:
Implementing arithmetic operations on aggregation/annotation.
Implementing conditional aggregates.
Fixing the errors related to the working eg. default values
Ok, actually my college exams are going on, as soon as they get over I will
definitely take some action towards drafting the proposal and posting it
here for review.
Thanks
Anubhav
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsub
Hi Anubhav,
Part of the GSoC "audition" process is for you to do this analysis
yourself. The GSoC wiki page lists a couple of tickets, and links to a wiki
page that describes the problem in depth. We're looking for people who can
take that initial direction, investigate the underlying problem, and
I need some suggestions related to improving the error message. I have gone
through some tickets but I would like to know the existing issues that need
to be resolved first than others, I mean those issues which need more
attention.
Thanking You
Anubhav
--
You received this message because yo
On Sunday, February 16, 2014 4:35:05 AM UTC+5:30, Florian Apolloner wrote:
>
> On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote:
>>
>> Well I will see what I put in my proposal..it will be based on
>> aggregation/annotation as well as improving the error message part as
I am not trying to say that I can solve all the issues myself, that is no
way possible. But I had wanted to base my work on aggregation part but I
think quite has been done so I just said that I would now explore other
areas as well. I have no intention of telling that I could do all, I merely
On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote:
>
> Well I will see what I put in my proposal..it will be based on
> aggregation/annotation as well as improving the error message part as
> before...I might now look to other things as well like improving tests as
> well.
Well I will see what I put in my proposal..it will be based on
aggregation/annotation as well as improving the error message part as
before...I might now look to other things as well like improving tests as
well.
--
You received this message because you are subscribed to the Google Gro
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,
Apart from the issues and tickets mentioned in the idea pages and some
other tickets/issues which I have found is there anything that anyone would
suggest for working on the aggregation/annotation part, like if there is
any issue which hasn't been picked up in tickets or anything else,if
somet
On Sun, Feb 9, 2014 at 5:02 AM, Christopher Medrela wrote:
> There is a list of ideas [1] and both improving aggregates and annotations
> as well as improving error messages are listed there, so I suppose these
> ideas are still open.
>
They're definitely still "open" in the sense that the probl
On 8 févr. 2014, at 22:02, Christopher Medrela wrote:
> AFAIK, there is no problem if there is more than one student working on the
> same idea.
In practice, I don't think we would allocate two slots to the same idea.
However, an proposal that wasn't thoroughly discussed on this mailing-list h
There is a list of ideas [1] and both improving aggregates and annotations
as well as improving error messages are listed there, so I suppose these
ideas are still open.
Google doesn't allow you to submit your proposal before March 10, but the
submission is only a formality and this doesn't me
Well I am thinking to work on aggregates and annotation, and improving the
error messages part.
I just want to know if these are still open.
And what is the procedure if more than one student submit similar proposals
or what if one submits it before then whether it remains open for another?
Can w
On Sat, Aug 21, 2010 at 2:01 AM, Alex Gaynor wrote:
> My
> recommendation would be for any changes in Django itself to be merged,
> including the new form fields, but for the MongoDB backend (and,
> indeed, any future backends) to live external to Django,
I agree. I'd like to see the first step t
Hey Alex,
Thanks for the great work on this! I haven't had a chance to check it out in
a while, but looking forward to diving back in when my schedule allows. I
did start looking into porting list fields to postgres, but haven't made
much progress yet.
Personally I think your recommendation re me
Hello all,
With this past week GSOC has officially come to it's close, and I'm
here to report on the status of the query-refactor. The original
purpose of this branch was to do refactorings to the internals of the
ORM, and produce a prototype backend for a non-relational database to
demonstrate t
On Fri, Jul 23, 2010 at 12:59 AM, Russell Keith-Magee
wrote:
> On Fri, Jul 23, 2010 at 4:37 AM, Alex Gaynor wrote:
>> Hey all,
>>
>> As I said in my last update, this week I've been working on some
>> ListField stuff. So far I have a basic ListField implemented, with a
>> syntax of models.ListFi
On Fri, Jul 23, 2010 at 4:37 AM, Alex Gaynor wrote:
> Hey all,
>
> As I said in my last update, this week I've been working on some
> ListField stuff. So far I have a basic ListField implemented, with a
> syntax of models.ListField(models.IntegerField()). However, there are
> a number of questio
Awesome! I've been really enjoying playing around with your code so far—I'm
actually building a small project off of it for fun—and the addition of
ListFields has been one of the things I've been waiting for. Embedded
documents is definitely also high on my list.
1) It would be awesome to have Lis
Hey all,
As I said in my last update, this week I've been working on some
ListField stuff. So far I have a basic ListField implemented, with a
syntax of models.ListField(models.IntegerField()). However, there are
a number of questions that have cropped up:
1) Should support for PostgreSQL (and
Hey all,
The last while has been spent continuing the fight to make aggregates
work correctly, Russ provided some good insight that's gotten me
farther on it. All that code is in my query-refactor-aggregates
branch on github, as it's not fully working ATM. This week I also
pushed a few updates t
On Tue, Jun 22, 2010 at 10:01 AM, Alex Gaynor wrote:
> Hey all,
>
> This past week was mostly spent getting lookup's working (and
> negation), that's gone fairly well. Well enough, in fact, that I
> spent most of today getting some low hanging fruit working: namely
> ordering, slicing, and values
+ 1 emulation
2010/6/22 Alex Gaynor :
> Hey all,
>
> This past week was mostly spent getting lookup's working (and
> negation), that's gone fairly well. Well enough, in fact, that I
> spent most of today getting some low hanging fruit working: namely
> ordering, slicing, and values. In slicing w
Hey all,
This past week was mostly spent getting lookup's working (and
negation), that's gone fairly well. Well enough, in fact, that I
spent most of today getting some low hanging fruit working: namely
ordering, slicing, and values. In slicing we've come to an
interesting design decision. Atte
Hey all,
Another week's gone by (and remarkably quickly if I do say so myself).
Since last we spoke I've gotten updates to work, basic filters,
cleaned up some fun messes in the source code, added support for
count(), tests for ForeignKeys, and began investigating more complex
lookup types. Here
Hey all,
If you saw my email last week you know that my goal for the bulk of
the GSOC work was going to be refactoring the Query class to be less
SQL/relational db specific. After spending much of last week taking a
few different approach at this it's become clear to me that that
approach would r
Hey all,
As you're likely aware this summer I'll be a GSOC student responsible
for query-refactor (aka "NoSQL") in Django. Basically the next couple
of weeks are going to involve me ripping up a bunch of internals, and
in the interest of keeping the SVN branch stable I'll be committing
that work
28 matches
Mail list logo
