Re: Google Summer of Code 2019

[akki]

Hi

One of the most difficult things for me while preparing my GSoC proposal 
was getting myself acquainted to Django's humungous code base.
To prepare a proposal one should know what modules they would need to 
modify & what part of the code they will need to work with. To do that one 
should *at least* know what is the role of a particular module/file in the 
big picture of Django's code. For me, even though I had drilled down that I 
had to work just with django/db, I still had the task of figuring out the 
working of *so* many modules. There were *models.options, models.sql.query, 
models.sql.compiler, migrations.autodetector, migrations.loader, 
migrations.optimizer*, *backends.features*, *backends.introspection*, 
*backends.operations*, *backends.schema* and many more which were somehow 
connected to each other & doing something but I had no easy way to know 
what.
I think putting an individual README to places like django/core/ 
<https://github.com/django/django/tree/master/django/core>, django/db/models 
<https://github.com/django/django/tree/master/django/db/models>/, etc. with 
even a 1-2 line description of what purpose each of the folder/file (or at 
least the convoluted ones) in that folder serve might be great help to 
newbie programmers - just not for GSoC but any new contributor.
I understand that the work required to make this happen might be quite big 
and complex (maybe big enough to make it a GSoC project in itself, but 
Google doesn't accept purely documentation projects for GSoC IIRC) but 
might be achievable if merged in parts.


@Parth I am Django's GSoC fellow for 2016. If there is any way I could help 
you, feel free to reach me out 
<https://gist.github.com/akki/b438292c2c3cf199012f#5-about-me>. For other 
fellows, you can search for Django in the archives of GSoC's website 
<https://developers.google.com/open-source/gsoc/past-summers>.
Also, a quick way to ask questions about contributing to Django from the 
community is the IRC channel #django-dev


On Wednesday, 16 January 2019 21:33:55 UTC+7, Tim Graham wrote:
>
> Org applications for Google's Summer of Code are now open (deadline 
> February 6). Do you think the Django Software Foundation should participate?
>
> We haven't had any high quality student applications that we could accept 
> for the past two years.
>
> Perhaps it's partly a function of a poor ideas page (
> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we don't 
> do a great job of publicizing our involvement and attracting high quality 
> students. Perhaps it's because the student payment isn't all that much 
> (+/-$6000 USD, depending on student's country)* for the amount of work 
> involved (also, students have to put in a lot of work up front in their 
> application, with no guarantee of being accepted into the program).
>
> If you have any ideas about mentoring or suggesting a project, or if 
> you're serious about being a student (you should start contributing to 
> Django now if you don't already), please share.
>
> * https://developers.google.com/open-source/gsoc/help/student-stipends
>

-- 
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/94246e44-0a18-492e-bae9-5c340c5734a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introduction GSoC

[akki]

Also, if Django does participate in GSoC this year, they'll have an ideas page 
for it eventually similar to something like this - 
https://code.djangoproject.com/wiki/SummerOfCode2018.

The best thing that you can do today to improve your chances is start 
contributing!

-- 
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/6bccbc0f-347c-4a93-9dba-11fe2829da16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

My name is Akshesh Doshi (akki). I am a student at Indian Institute Of 
Technology, Roorkee (IITR). I have been contributing to Django 
<https://github.com/django/django/pulls/akki> for quite some time now and 
my experience has been really great till now. I found the community to be 
very welcoming and have learnt a lot in this period of time.

With this spirit I would like to work on the idea of "Custom Indexes" 
<https://code.djangoproject.com/wiki/SummerOfCode2016#Customindexes>  and 
extend it as my proposal for Google Summer of Code 2016 
<https://summerofcode.withgoogle.com/>.

I have started preparing my proposal and here is the initial draft 
<https://gist.github.com/akki/b438292c2c3cf199012f> of it. I would like to 
hear your thoughts regarding this. Also I wanted to discuss some points 
mentioned below. The timeline still needs work as I am still digging into 
the code of expressions to see how we can use them in FunctionalIndex. Any 
pointers/thoughts on that would be appreciated.

Key points:
  - Introduction to classed based indexes.
  - Support for custom classes to db_index.
  - Introduction of Meta.indexes.
  - Allowing fields to specify their own index type.
  - Support for a indexes/constraints API. 
  - Extend expressions into indexes.
  - Bring spatial indexes under the hood.

Points I would like to discuss:
 1) Would it be right to *create a IndexTogether class* (subclass of Index) 
and internally translate Meta.index_together to it ?
  This would allow something like -
  class Meta:
  indexes = [IndexTogether(['field1', 'field2'])]
I think this would let us keep a better track of any indexes (including 
those by `index_together`) that are being created. `Meta.index_together` 
would be internally translated to Meta.indexes. This might also be followed 
by deprecation of `index_together` if we want.

 2) 
*Handling Unique constraints via indexes.*  For handling of 
constraints, I was thinking of creating a UniqueIndex class which would 
handle any unique constraint on any column and allow other options like to 
make it deferrable.
  Right now fields with ``unique=True`` apply the unique constraints by 
using both the UNIQUE constraint in the CREATE TABLE statement and by 
creating an index for it. For example, in this model 
<https://gist.github.com/akki/56b6c3cac56073c9bf4d>, multiple (repeating) 
indexes are being generated for the `name` field (one by UNIQUE constraint, 
2 others manually, on postgresql). This takes more space and is also not 
good performancewise. This situation can also be mitigated by keeping a 
track of all unique constraints at only one place.
  So I was thinking of bringing the unique constraint totally under 
indexes. Maybe some `models.UniqueIndex()` could be used in meta.indexes to 
add constraints ? Any thoughts on it ?


I had also prepared a DEP (based on an earlier DEP by Marc Tamlyn), which 
is now a subset of this proposal.

Regards
Akshesh Doshi
(akki)

-- 
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/0c4f5d09-b714-4188-a70e-a3163480af97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

 expression subclasses which process field names as F() expressions. F() 
> > expressions may have to be changed (or a new concept introduced) which 
> can 
> > resolve the field, but doesn't try to do any joining. 
> > 
> > fullname_index=Index(ToLower('first_name'), ToLower('last_name')) -> 
> create 
> > index _fullname_index on (Lower(first_name), 
> > Lower(last_name)); 
> > 
> > Once the index is added to a model, the model can inject itself into the 
> > index, or the schema editor can use the originating model to get data it 
> > needs. No need to pass the model into the index type I think. Regarding 
> the 
> > name, I'm unsure if I prefer a name=Index() or an Index(name='') 
> approach. 
> > It'd be good to see that choice in your proposal with a couple of pros 
> and 
> > cons. 
> > 
> > 
> > Ok, onto the questions you actually asked. 
> > 
> > 1) I don't think it's necessary to have an IndexTogether type. 
> > Index('field_a', 'field_b') should be sufficient I think. If it's not 
> > sufficient, call out why. I'm also in favour of translating any 
> > index_together definitions into appropriate Index types. Then 
> SchemaEditor 
> > only needs to work with Index expressions and things remain simpler at 
> the 
> > boundary between model definition and migrations. 
> > 
> > 2) Again I think it's a good idea to internally create index classes 
> based 
> > on older (unique=True) definitions. Unique may not have to have it's own 
> > index type as it could (maybe) be a property of an Index. Again, I'll 
> leave 
> > that choice up to you, but it'd be good to see the pros/cons briefly 
> > discussed. 
> > 
> > Again, really good proposal! 
> > 
> > On Wednesday, 9 March 2016 01:46:02 UTC+11, akki wrote: 
> >> 
> >> Hi 
> >> 
> >> My name is Akshesh Doshi (akki). I am a student at Indian Institute Of 
> >> Technology, Roorkee (IITR). I have been contributing to Django for 
> quite 
> >> some time now and my experience has been really great till now. I found 
> the 
> >> community to be very welcoming and have learnt a lot in this period of 
> time. 
> >> 
> >> With this spirit I would like to work on the idea of "Custom Indexes" 
>  and 
> >> extend it as my proposal for Google Summer of Code 2016. 
> >> 
> >> I have started preparing my proposal and here is the initial draft of 
> it. 
> >> I would like to hear your thoughts regarding this. Also I wanted to 
> discuss 
> >> some points mentioned below. The timeline still needs work as I am 
> still 
> >> digging into the code of expressions to see how we can use them in 
> >> FunctionalIndex. Any pointers/thoughts on that would be appreciated. 
> >> 
> >> Key points: 
> >>   - Introduction to classed based indexes. 
> >>   - Support for custom classes to db_index. 
> >>   - Introduction of Meta.indexes. 
> >>   - Allowing fields to specify their own index type. 
> >>   - Support for a indexes/constraints API. 
> >>   - Extend expressions into indexes. 
> >>   - Bring spatial indexes under the hood. 
> >> 
> >> Points I would like to discuss: 
> >>  1) Would it be right to create a IndexTogether class (subclass of 
> Index) 
> >> and internally translate Meta.index_together to it ? 
> >>   This would allow something like - 
> >>   class Meta: 
> >>   indexes = [IndexTogether(['field1', 'field2'])] 
> >> I think this would let us keep a better track of any indexes 
> >> (including those by `index_together`) that are being created. 
> >> `Meta.index_together` would be internally translated to Meta.indexes. 
> This 
> >> might also be followed by deprecation of `index_together` if we want. 
> >> 
> >>  2) Handling Unique constraints via indexes. 
> >>   For handling of constraints, I was thinking of creating a 
> >> UniqueIndex class which would handle any unique constraint on any 
> column and 
> >> allow other options like to make it deferrable. 
> >>   Right now fields with ``unique=True`` apply the unique 
> constraints 
> >> by using both the UNIQUE constraint in the CREATE TABLE statement and 
> by 
> >> creating an index for it. For example, in this model, multiple 
> (repeating) 
> >> indexes are being generated for the `na

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

> Would you be able to support partial indexes as well?

I am not sure if I would be able to squash it in my GSOC timeline, but yes, 
I will definitely incorporate it (afterwards, if not during my GSOC). It 
should not be very hard to implement once I am able to make functional 
indexes work.

Index('field1', 'field2', name='some_index_across_two_columns'),
I think you meant ['field1', 'field2'] here.


> Index(...) would create one index from my perspective. Thus 
> Index('field_a', 'field_b') would do the same as 
> index_together=(('field_a', 'field_b'),) these days.
> Index(['f1', 'f2', ['f3', 'f4']]) looks way to confusing to me. That would 
> probably be better Index('f1'), Index('f2'), Index('f3', 'f4')
>
Yes, I had thought more about it after my last reply and reached the same 
conclusion. It would best if the indexes looked like -
   Index(['f1', 'f2']) # multi-column indexing.
   Index(['f1'], name='name_idx', type=models.Hash) # single-column 
hash type indexing.
There's no need to make it more complicated.


> Since we're talking about index_together, please keep unique_together in 
> mind ;)
>
unique_together is a whole another independent thing. It is the `ALTER 
TABLE  ADD CONSTRAINT` thing and is not required to be mixed 
with the `CREATE INDEX` things, IMO, unless I am missing something.

-- 
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/8521e120-1096-4cf0-beb6-9d5b5bdbbc85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

 

> What about calling the attribute something like "constraints" similar to 
> how it's done in SQLAlchemy [1]? For now the attribute can just contain a 
> list of Index() instances but that would also lay grounds for supporting 
> check constraints and other related table level options. 
>
Since we are just allowing instances of Index class and it's subclasses 
right now, I don't think there is much gain in naming it "constraints". It 
might even confuse the user.

-- 
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/090de3a1-63da-4897-9bb6-a7997a9b9610%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

I have updated my proposal 
<https://gist.github.com/akki/b438292c2c3cf199012f> and completed the 
timeline. I saw how expressions work and now have a clear idea of how they 
would be used in indexes - I have added a short description of the same in 
my proposal.

Please have a look. I would love to hear any suggestions for further 
improvement. If there are any questions, I will be happy to answer.

Regards
Akshesh Doshi
(akki)

-- 
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/5ebdb9b6-5406-40b1-a18f-ede8851192c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi Annsi

Yes, the AddIndex operation would detect the changes and the user would not 
have full control over the generated SQL.

I don't know if it would be a good idea to mix index definitions with 
fields while creating models. Users have traditionally been defining fields 
that way and indexes feel more like a "Meta" property to me. Constraints 
can also be added to Meta (maybe merged together with indexes) whenever 
they arrive, but I don't how soon they will be included.

Regards
Akshesh Doshi
(akki)

On Monday, 14 March 2016 12:53:30 UTC+5:30, Anssi Kääriäinen wrote:
>
> On Thu, Mar 10, 2016 at 8:17 AM, Markus Holtermann 
> > wrote: 
> > Hi Akshesh, 
> > 
> > thank you for your proposal! Sounds like a good plan. 
> > 
> > On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote: 
> > 
> >>> Once the index is added to a model, the model can inject itself into 
> the 
> >>> index, or the schema editor can use the originating model to get data 
> it 
> >>> needs. No need to pass the model into the index type I think. 
> Regarding the 
> >>> name, I'm unsure if I prefer a name=Index() or an Index(name='') 
> approach. 
> >>> It'd be good to see that choice in your proposal with a couple of pros 
> and 
> >>> cons. 
> >> 
> >> 
> >> Well, since we are defining these indexes in a list (to be stored in 
> >> Meta.indexes) I would go with the Index(name='') approach. 
> > 
> > 
> > I'd prefer the Index(name='') approach 
> > 
> > class MyModel(models.Model): 
> > field1 = models.CharField() 
> > field2 = models.CharField() 
> > 
> > class Meta: 
> > indexes = [ 
> > Index('field1', 'field2', 
> name='some_index_across_two_columns'), 
> > 'field2',  # Would be the same as Index('field2'), an index 
> on 
> > this one column -- name derived from field name: field2_index 
> > Index(ToLower('field1')),  # A functional index on field1 -- 
> > name derived from field name and functions: field1_tolower_index 
> > ] 
> > 
> > That way you should also be able to check for duplicate index names. 
>
> How about 
>
> class MyModel(models.Model): 
> field1 = models.CharField() 
> field2 = models.CharField() 
>
> field1_idx = models.Index('field1') 
> field2_lower_idx = models.Index(ToLower('field2')) 
>
> The main advantage is that the same syntax can be used for custom 
> indexes, constraints, composite fields and so on. Internally we could 
> of course have the same representation for indexes as before. 
>
>  - Anssi 
>

-- 
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/f07f1303-fd25-43b9-b50f-353da0c69ad3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

>
>
> you can't have identical indexes defined in multiple ways with the same 
> names.
>
 
Yes, I will be checking for the duplications at the autodetector level 
itself. We need to take care that no two indexes are for the same fields, 
and none of them have a clashing name. On such an occurrence, we can raise 
an error like "Multiple indexes have been set for 'field1' " or merge them 
ourself internally (if they mean exactly the same).

-- 
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/6a0c0ef6-1664-45d9-88d0-8e9532c5efd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi Tim

Thanks for the feedback.

Instead of aiming for one huge patch to be merged at the end of the summer, 
> I'd suggest to think about whether you can break up the work in chunks that 
> can be merged incrementally. This should decrease the risk that comes with 
> a huge patch going stale and makes code review much easier.
>
Yes, I see how that would be useful in the long run. Although I had made 
the timeline keeping in mind that the work is done in a progressive way but 
it would definitely be good to see that this is clearly (and more 
explicitly) reflected in the proposal as well. Will update my proposal ASAP 
to incorporate this change.


> It's helpful if you can add your other commitments for the summer such as 
> holidays, vacations, etc.
>
To be honest, there aren't any commitments I have for these summers. I 
would be having my breaks from college and am pretty much free to work on 
this.
I'll to see if there's anything else worth mentioning in the proposal.

-- 
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/743c2cef-51b1-464a-9915-0c6695c46f4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

I had updated my proposal to include the various points that were discussed 
earlier in this thread. I have now also incorporated the changes that were 
recently suggested by Tim.

Thanks

-- 
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/41d8c684-e8fe-4051-82bc-2b74c8b348be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

Hi

I have submitted my proposal on GSoC's website. You can find it 
at https://summerofcode.withgoogle.com/serve/5167032660131840/. It would 
get locked (from any further editing) at 25 March 19:00 UTC (which is 
almost 11 hours from now).

-- 
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/91b0a809-3a51-4165-8bd4-80720f5181bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[akki]

>
>
> That is a bit too strict; sometimes it does make sense to provide more 
> than 
> one kind of index on one field. As a trivial example, you may want to 
> support 
> case-sensitive uniqueness as well as case-insensitive search (say, for 
> user- 
> names). 
>
Ohh yes definitely, I meant no two identical indexes on the same field. 
Sorry for the wrong choice of words.

-- 
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/119f21bf-b6fa-480c-a100-d779c7092a5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC community bonding period Update

[akki]

Hi

The community bonding period of GSoC is about to end and here is an update 
of my work during the community bonding period. I have taken the 
opportunity to use this time to research about the various things that 
would help me during the coding period of GSoC and also to help the 
community with the bug reporting/solving/reviewing process.



I found and went through discussions of various tickets to get an idea of 
the various issues that we are facing and that can be solved via my GSoC 
project . They are listed below:
https://code.djangoproject.com/ticket/20581
​
https://code.djangoproject.com/ticket/20888
​
https://code.djangoproject.com/ticket/23577
​
​
https://code.djangoproject.com/ticket/24082
https://code.djangoproject.com/ticket/24530
​
https://code.djangoproject.com/ticket/25752
https://code.djangoproject.com/ticket/26610 (reviewed only).

There was also a discussion on the mailing list which was also helpful:
https://groups.google.com/forum/#!topic/django-developers/7pMxh2JF1lo

Here I have prepared of the basic queries for creating and deleting indexes 
in the various backends we support which would helpful while writing code 
in the schema - 
https://gist.github.com/akki/73e7b0b7098e32594237749eb79a0960



Other than that, I was trying to solve a couple of bugs that I had found 
(but haven't found the fix); one of which I have reported recently - 
https://code.djangoproject.com/ticket/26624.
I will report the other one as well soon.

I worked on some already existing issues as well:
https://code.djangoproject.com/ticket/21523 - PR: 
https://github.com/django/django/pull/6468
https://code.djangoproject.com/ticket/15220 - WIP version: 
https://github.com/akki/django/tree/ticket_15220

​​
​Regards​
akki

-- 
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/ce1a1e7a-9049-4b00-aae7-3a883528c00a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[akki]

Corresponding ticket - #26622 

On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote:
>
> While writing timezone tests for 
> https://github.com/django/django/pull/6243 I ran into some issues where 
> pytz seemed to be required for just about every database and platform 
> combination except postgres on linux. The docs for timezone support (
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>
> Installing pytz  is highly recommended, but 
>> may not be mandatory depending on your particular database backend, 
>> operating system and time zone. If you encounter an exception querying 
>> dates or times, please try installing it before filing a bug. 
>
>
> I tried to find some documentation on the broader internet that would more 
> accurately describe when and for what platforms pytz is actually required 
> for timezone support, but was unable to find anything. I've opened a new 
> ticket https://code.djangoproject.com/ticket/26622 to clarify more 
> explicitly when pytz is required.
>
> However, I'm wondering if we should just go all-in on pytz and require it 
> for timezone support. I've not run a Django site with timezone support 
> without pytz, so I'm not sure what exact limitations exist or why you'd 
> want to use timezone support without pytz. I'd be interested in hearing use 
> cases for not requiring pytz if there are any. Explicitly requiring pytz 
> will make test writing a lot easier, and will remove any doubt about 
> whether or not pytz is required for users.
>
> Josh 
>

-- 
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/02554482-7301-43c2-b279-ca2c24393e9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[akki]

Corresponding ticket - #26622 .

On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote:
>
> While writing timezone tests for 
> https://github.com/django/django/pull/6243 I ran into some issues where 
> pytz seemed to be required for just about every database and platform 
> combination except postgres on linux. The docs for timezone support (
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>
> Installing pytz  is highly recommended, but 
>> may not be mandatory depending on your particular database backend, 
>> operating system and time zone. If you encounter an exception querying 
>> dates or times, please try installing it before filing a bug. 
>
>
> I tried to find some documentation on the broader internet that would more 
> accurately describe when and for what platforms pytz is actually required 
> for timezone support, but was unable to find anything. I've opened a new 
> ticket https://code.djangoproject.com/ticket/26622 to clarify more 
> explicitly when pytz is required.
>
> However, I'm wondering if we should just go all-in on pytz and require it 
> for timezone support. I've not run a Django site with timezone support 
> without pytz, so I'm not sure what exact limitations exist or why you'd 
> want to use timezone support without pytz. I'd be interested in hearing use 
> cases for not requiring pytz if there are any. Explicitly requiring pytz 
> will make test writing a lot easier, and will remove any doubt about 
> whether or not pytz is required for users.
>
> Josh 
>

-- 
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/395a2065-6172-4643-8bcd-300323e54ad3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Google Summer of Code Updates - Class based indexes

[akki]

Hi

Here is the list of tasks that I have done related to my GSoC project till 
now.

   - Introducing the django.db.models.indexes module.
  - Writing the BaseIndex class - kind of skeleton for all the index 
  classes.
  - Writing the Index class for the default (B-Tree) indexes.
   - Add CreateIndex/DropIndex migration operation for adding and removing 
   the indexes.
   - Add methods to schema for the same.
   - Writing corresponding tests for migrations and schema.
   - Create docs for indexes and the new operations.

#26709 <https://code.djangoproject.com/ticket/26709/> is the ticket 
 corresponding to the current checkpoint. The code can be found at 
https://github.com/django/django/pull/6726.


Regards
Akshesh (akki)

-- 
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/da61fb0d-cfec-4bf5-a59f-ac3cfe7a9fbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

Progress on previous PR:

   - Design changes in ModelState.options.indexex and RemoveIndex migration
   - Improved algorithm for index naming
   - Other cleanups and cosmetic changes

Other than that I have started working on the second checkpoint as well 
which is to add support for creating class based index in the Meta class. 
The code can be seen at https://github.com/akki/django/pull/1/

Regards
akki

-- 
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/e198f6ce-2693-49c7-abf2-18f089098c75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

This week's work on previous PR:

   - Change in signature of Index class
   - Write tests for the Index class
   - Address all issues on PR

The previous PR has been merged. Now indexes can be added using the AddIndex 
migration 
.


The next checkpoint is to add support for using Index classes from model's 
Meta class. Corresponding ticket - #26808 
. The code is almost ready, I 
will be sending a pull request soon.

-- 
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/287c3128-5752-43bc-a68e-97ecf1ef1468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Restructure index migrations
   PR  - https://github.com/django/django/pull/6866
   Modified the internal working of migrations/schema methods related to 
   indexes. This mainly aims at stabilising the newly added migrations for 
   Index class.


   - Introduce Meta.indexes
   PR ready for review at https://github.com/django/django/pull/6857.
   Ticket - https://code.djangoproject.com/ticket/26808


On Tuesday, 28 June 2016 18:44:37 UTC+5:30, thinkwel...@gmail.com wrote:
>
> Wonderful!  I make heavy use of btree_gin in one of my projects; will be 
> great to have these new Index classes!
>
> On Monday, June 27, 2016 at 6:51:31 PM UTC-4, Tim Graham wrote:
>>
>> Support for more index types is planned. This is only part 1 of the work. 
>> Please see https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 
>> for the timeline.
>>
>> On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com 
>> wrote:
>>>
>>> Will it be possible to create indexes other than btree? In reviewing the 
>>> code it doesn't look like it but I hope I'm wrong. It'd be awesome to 
>>> support the many more specific index options without using run_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/26b952b5-ae2c-4504-b064-00c0de60a693%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Restructure index migrations - Polished according to all reviews, the 
   PR <https://github.com/django/django/pull/6866> has been merged.
   - Introduce Meta.indexes - Updated PR 
   <https://github.com/django/django/pull/6857> according to suggestions as 
   per reviews.
   - Improve schema's index name creating algorithm - #24442 
   <https://code.djangoproject.com/ticket/24442> !6898 
   <https://github.com/django/django/pull/6898>.
   - Add support for indexes to inspectdb - This depends on !6857 
   <https://github.com/django/django/pull/6857> so I will send a PR once 
   indexes are added to Meta class; Current work on my local branch 
   - https://github.com/akki/django/commits/gsoc-indexes-inspectdb

On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:

>
>- Restructure index migrations
>PR  - https://github.com/django/django/pull/6866
>Modified the internal working of migrations/schema methods related to 
>indexes. This mainly aims at stabilising the newly added migrations for 
>Index class.
>
>
>- Introduce Meta.indexes
>PR ready for review at https://github.com/django/django/pull/6857.
>Ticket - https://code.djangoproject.com/ticket/26808
>
>
> On Tuesday, 28 June 2016 18:44:37 UTC+5:30, thinkwel...@gmail.com wrote:
>>
>> Wonderful!  I make heavy use of btree_gin in one of my projects; will be 
>> great to have these new Index classes!
>>
>> On Monday, June 27, 2016 at 6:51:31 PM UTC-4, Tim Graham wrote:
>>>
>>> Support for more index types is planned. This is only part 1 of the 
>>> work. Please see 
>>> https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 for the 
>>> timeline.
>>>
>>> On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com 
>>> wrote:
>>>>
>>>> Will it be possible to create indexes other than btree? In reviewing 
>>>> the code it doesn't look like it but I hope I'm wrong. It'd be awesome to 
>>>> support the many more specific index options without using run_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/3f3c7092-02f7-47b3-ae16-5b71083b06ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Introduce Meta.indexes
   PR - https://github.com/django/django/pull/6857.
   Ticket - https://code.djangoproject.com/ticket/26808.
   Made a design change so that index can drop it's model attribute by 
   introducing *Index.set_name_with_model* method
   Wrote some left out tests for *related_dependencies*.
   
   - Fixed #24442 <https://code.djangoproject.com/ticket/24442> - Improve 
   schema's index name creating algorithm
   PR  - https://github.com/django/django/pull/6898 
   <https://github.com/django/django/pull/6866>
   Updated according to reviews and suggestions.
   
   - Resolved bug when unique_together was dropped along with it's field
   PR - https://github.com/django/django/pull/6926.
   Initially wrote a temporary fix (which left out some other corner cases) 
   to the problem (afterwards I realised the better fix and sent PR).
   Other comments about the issue on the ticket - 
   https://code.djangoproject.com/ticket/26180.
   Resolved a similar issue that had crept up for Meta.indexes - updated 
   !6857 <https://github.com/django/django/pull/6926> accordingly.
   
   
On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote:
>
>
>- Restructure index migrations - Polished according to all reviews, 
>the PR <https://github.com/django/django/pull/6866> has been merged.
>- Introduce Meta.indexes - Updated PR 
><https://github.com/django/django/pull/6857> according to suggestions 
>as per reviews.
>- Improve schema's index name creating algorithm - #24442 
><https://code.djangoproject.com/ticket/24442> !6898 
><https://github.com/django/django/pull/6898>.
>- Add support for indexes to inspectdb - This depends on !6857 
><https://github.com/django/django/pull/6857> so I will send a PR once 
>indexes are added to Meta class; Current work on my local branch - 
>    https://github.com/akki/django/commits/gsoc-indexes-inspectdb
>
> On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:
>
>>
>>- Restructure index migrations
>>PR  - https://github.com/django/django/pull/6866
>>Modified the internal working of migrations/schema methods related to 
>>indexes. This mainly aims at stabilising the newly added migrations for 
>>Index class.
>>
>>
>>- Introduce Meta.indexes
>>PR ready for review at https://github.com/django/django/pull/6857.
>>Ticket - https://code.djangoproject.com/ticket/26808
>>
>>
>> On Tuesday, 28 June 2016 18:44:37 UTC+5:30, thinkwel...@gmail.com wrote:
>>>
>>> Wonderful!  I make heavy use of btree_gin in one of my projects; will be 
>>> great to have these new Index classes!
>>>
>>> On Monday, June 27, 2016 at 6:51:31 PM UTC-4, Tim Graham wrote:
>>>>
>>>> Support for more index types is planned. This is only part 1 of the 
>>>> work. Please see 
>>>> https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 for the 
>>>> timeline.
>>>>
>>>> On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com 
>>>> wrote:
>>>>>
>>>>> Will it be possible to create indexes other than btree? In reviewing 
>>>>> the code it doesn't look like it but I hope I'm wrong. It'd be awesome to 
>>>>> support the many more specific index options without using run_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/44fea212-11ee-46db-9e49-15ec7d09b042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   - Fixed #24442 <http://code.djangoproject.com/ticket/24442> - Improved 
   schema's index name creating algorithm
   Updated !6898 <http://github.com/django/django/pull/6898> to take all 
   column names into account while creating index name


   - Add support for column ordering (ASC/DESC) in class based indexes
   Somewhat provides the feature requested in #20888 
   <https://code.djangoproject.com/ticket/20888#comment:10>
   WIP code on my branch - 
   https://github.com/akki/django/commits/gsoc-indexes-order
   Modifying introspection of all databases to return column order as well 
   (required for testing) -- implementation for Oracle remaining.
   

   - Implement Hash index class
   WIP implementation at 
   https://github.com/akki/django/commits/gsoc-indexes-hash
   Currently implemented only for postgresql because that's the only 
   backend which fully supports it AFAIK (MySQL supports for some storage 
   engines but neither for MyISAM nor InnoDB).


On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote:
>
>
>- Introduce Meta.indexes
>PR - https://github.com/django/django/pull/6857.
>Ticket - https://code.djangoproject.com/ticket/26808.
>Made a design change so that index can drop it's model attribute by 
>introducing *Index.set_name_with_model* method
>Wrote some left out tests for *related_dependencies*.
>
>- Fixed #24442 <https://code.djangoproject.com/ticket/24442> - Improve 
>schema's index name creating algorithm
>PR  - https://github.com/django/django/pull/6898 
><https://github.com/django/django/pull/6866>
>Updated according to reviews and suggestions.
>
>- Resolved bug when unique_together was dropped along with it's field
>PR - https://github.com/django/django/pull/6926.
>Initially wrote a temporary fix (which left out some other corner 
>cases) to the problem (afterwards I realised the better fix and sent PR).
>Other comments about the issue on the ticket - 
>https://code.djangoproject.com/ticket/26180.
>Resolved a similar issue that had crept up for Meta.indexes - updated 
>    !6857 <https://github.com/django/django/pull/6926> accordingly.
>
>
> On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote:
>>
>>
>>- Restructure index migrations - Polished according to all reviews, 
>>the PR <https://github.com/django/django/pull/6866> has been merged.
>>- Introduce Meta.indexes - Updated PR 
>><https://github.com/django/django/pull/6857> according to suggestions 
>>as per reviews.
>>- Improve schema's index name creating algorithm - #24442 
>><https://code.djangoproject.com/ticket/24442> !6898 
>><https://github.com/django/django/pull/6898>.
>>- Add support for indexes to inspectdb - This depends on !6857 
>><https://github.com/django/django/pull/6857> so I will send a PR once 
>>indexes are added to Meta class; Current work on my local branch - 
>>https://github.com/akki/django/commits/gsoc-indexes-inspectdb
>>
>> On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:
>>
>>>
>>>- Restructure index migrations
>>>PR  - https://github.com/django/django/pull/6866
>>>Modified the internal working of migrations/schema methods related 
>>>to indexes. This mainly aims at stabilising the newly added migrations 
>>> for 
>>>Index class.
>>>
>>>
>>>- Introduce Meta.indexes
>>>PR ready for review at https://github.com/django/django/pull/6857.
>>>Ticket - https://code.djangoproject.com/ticket/26808
>>>
>>>
>>> On Tuesday, 28 June 2016 18:44:37 UTC+5:30, thinkwel...@gmail.com wrote:
>>>>
>>>> Wonderful!  I make heavy use of btree_gin in one of my projects; will 
>>>> be great to have these new Index classes!
>>>>
>>>> On Monday, June 27, 2016 at 6:51:31 PM UTC-4, Tim Graham wrote:
>>>>>
>>>>> Support for more index types is planned. This is only part 1 of the 
>>>>> work. Please see 
>>>>> https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 for the 
>>>>> timeline.
>>>>>
>>>>> On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com 
>>>>> wrote:
>>>>>>
>>>>>> Will it be possible to create indexes other than btree? In reviewing 
>>>>>> the code it doesn't look like it but I hope I'm wrong. It'd be awesome 
>>>>>> to 
>>

Re: Google Summer of Code Updates - Class based indexes

[akki]

Hi Jani

Thanks a lot for offering help. I did face some issues with the Oracle 
setup in the beginning but was able to resolve them yesterday. :)
You are most welcomed to review the PR and offer any suggestions for 
improvement at https://github.com/django/django/pull/6982/. The work 
related to the feature is in progress but the introspection-related work is 
mostly complete.

Regards
Akshesh(akki)

On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:
>
> Hi,
>
> On 26.07.2016 04:28, akki wrote:
>
>
>
>- Fixed #24442 <http://code.djangoproject.com/ticket/24442> - Improved 
>schema's index name creating algorithm
>Updated !6898 <http://github.com/django/django/pull/6898> to take all 
>column names into account while creating index name 
>
>
>- Add support for column ordering (ASC/DESC) in class based indexes
>Somewhat provides the feature requested in #20888 
><https://code.djangoproject.com/ticket/20888#comment:10>
>WIP code on my branch - 
>https://github.com/akki/django/commits/gsoc-indexes-order
>Modifying introspection of all databases to return column order as 
>well (required for testing) -- implementation for Oracle remaining.
>
>
> If you get stuck with Oracle I can lend a hand to help to figure out the 
> details.
>
>
>- Implement Hash index class
>WIP implementation at 
>https://github.com/akki/django/commits/gsoc-indexes-hash
>Currently implemented only for postgresql because that's the only 
>backend which fully supports it AFAIK (MySQL supports for some storage 
>engines but neither for MyISAM nor InnoDB). 
>
>
> On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote: 
>>
>>
>>- Introduce Meta.indexes
>>PR - https://github.com/django/django/pull/6857.
>>Ticket - https://code.djangoproject.com/ticket/26808.
>>Made a design change so that index can drop it's model attribute by 
>>introducing *Index.set_name_with_model* method
>>Wrote some left out tests for *related_dependencies*.
>>
>>- Fixed #24442 <https://code.djangoproject.com/ticket/24442> - 
>>Improve schema's index name creating algorithm
>>PR  - https://github.com/django/django/pull/6898 
>><https://github.com/django/django/pull/6866>
>>Updated according to reviews and suggestions.
>>
>>- Resolved bug when unique_together was dropped along with it's field
>>PR - https://github.com/django/django/pull/6926.
>>Initially wrote a temporary fix (which left out some other corner 
>>cases) to the problem (afterwards I realised the better fix and sent PR).
>>Other comments about the issue on the ticket -  
>><https://code.djangoproject.com/ticket/26180>
>>https://code.djangoproject.com/ticket/26180.
>>Resolved a similar issue that had crept up for Meta.indexes - updated 
>>!6857 <https://github.com/django/django/pull/6926> accordingly.
>>
>>
>> On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote: 
>>>
>>>
>>>- Restructure index migrations - Polished according to all reviews, 
>>>the PR <https://github.com/django/django/pull/6866> has been merged. 
>>>- Introduce Meta.indexes - Updated PR 
>>><https://github.com/django/django/pull/6857> according to 
>>>suggestions as per reviews. 
>>>- Improve schema's index name creating algorithm - #24442 
>>><https://code.djangoproject.com/ticket/24442> !6898 
>>><https://github.com/django/django/pull/6898>.
>>>- Add support for indexes to inspectdb - This depends on !6857 
>>><https://github.com/django/django/pull/6857> so I will send a PR 
>>>once indexes are added to Meta class; Current work on my local branch -  
>>><https://github.com/akki/django/commits/gsoc-indexes-inspectdb>
>>>https://github.com/akki/django/commits/gsoc-indexes-inspectdb 
>>>
>>> On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:
>>>
>>>>
>>>>- Restructure index migrations
>>>>PR  - https://github.com/django/django/pull/6866
>>>>Modified the internal working of migrations/schema methods related 
>>>>to indexes. This mainly aims at stabilising the newly added migrations 
>>>> for 
>>>>Index class. 
>>>>
>>>>
>>>>- Introduce Meta.indexes
>>>>PR ready for review at https://github.com/django/django/pull/

Re: Google Summer of Code Updates - Class based indexes

[akki]

   - Add support for column ordering (ASC/DESC) in class based indexes
   Completed - tests, docs, code
   PR - https://github.com/django/django/pull/6982
   
   - Implement Hash index class
   Add capability to get type of index in introspection (required for 
   testing this feature)
   Completed - Add tests, docs, code
   PR - https://github.com/django/django/pull/6995
   Ticket - https://code.djangoproject.com/ticket/26974
   
   - Some minor changes in !6857 
   <https://github.com/django/django/pull/6857>

Other than these, I also had a look at btree_gin indexes and extensions but 
haven't started the implementation yet.

On Wednesday, 27 July 2016 20:26:38 UTC+5:30, akki wrote:
>
> Hi Jani
>
> Thanks a lot for offering help. I did face some issues with the Oracle 
> setup in the beginning but was able to resolve them yesterday. :)
> You are most welcomed to review the PR and offer any suggestions for 
> improvement at https://github.com/django/django/pull/6982/. The work 
> related to the feature is in progress but the introspection-related work is 
> mostly complete.
>
> Regards
> Akshesh(akki)
>
> On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:
>>
>> Hi,
>>
>> On 26.07.2016 04:28, akki wrote:
>>
>>
>>
>>- Fixed #24442 <http://code.djangoproject.com/ticket/24442> - 
>>Improved schema's index name creating algorithm
>>Updated !6898 <http://github.com/django/django/pull/6898> to take all 
>>column names into account while creating index name 
>>
>>
>>- Add support for column ordering (ASC/DESC) in class based indexes
>>Somewhat provides the feature requested in #20888 
>><https://code.djangoproject.com/ticket/20888#comment:10>
>>WIP code on my branch - 
>>https://github.com/akki/django/commits/gsoc-indexes-order
>>Modifying introspection of all databases to return column order as 
>>well (required for testing) -- implementation for Oracle remaining.
>>
>>
>> If you get stuck with Oracle I can lend a hand to help to figure out the 
>> details.
>>
>>
>>- Implement Hash index class
>>WIP implementation at 
>>https://github.com/akki/django/commits/gsoc-indexes-hash
>>    Currently implemented only for postgresql because that's the only 
>>backend which fully supports it AFAIK (MySQL supports for some storage 
>>engines but neither for MyISAM nor InnoDB). 
>>
>>
>> On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote: 
>>>
>>>
>>>- Introduce Meta.indexes
>>>PR - https://github.com/django/django/pull/6857.
>>>Ticket - https://code.djangoproject.com/ticket/26808.
>>>Made a design change so that index can drop it's model attribute by 
>>>introducing *Index.set_name_with_model* method
>>>Wrote some left out tests for *related_dependencies*.
>>>
>>>- Fixed #24442 <https://code.djangoproject.com/ticket/24442> - 
>>>Improve schema's index name creating algorithm
>>>PR  - https://github.com/django/django/pull/6898 
>>><https://github.com/django/django/pull/6866>
>>>Updated according to reviews and suggestions.
>>>
>>>- Resolved bug when unique_together was dropped along with it's field
>>>PR - https://github.com/django/django/pull/6926.
>>>Initially wrote a temporary fix (which left out some other corner 
>>>cases) to the problem (afterwards I realised the better fix and sent PR).
>>>Other comments about the issue on the ticket -  
>>><https://code.djangoproject.com/ticket/26180>
>>>https://code.djangoproject.com/ticket/26180.
>>>Resolved a similar issue that had crept up for Meta.indexes - 
>>>updated !6857 <https://github.com/django/django/pull/6926> 
>>>accordingly.
>>>
>>>
>>> On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote: 
>>>>
>>>>
>>>>- Restructure index migrations - Polished according to all reviews, 
>>>>the PR <https://github.com/django/django/pull/6866> has been merged. 
>>>>- Introduce Meta.indexes - Updated PR 
>>>><https://github.com/django/django/pull/6857> according to 
>>>>suggestions as per reviews. 
>>>>- Improve schema's index name creating algorithm - #24442 
>>>><https://code.djangoproject.com/ticket/24442> !6898 
>>>><https://github.com/djang

Re: Trac spam attack / spam filter reactivated

[akki]

Hi

Recently, I would say since the past week, many of my activities on Trac 
are being reported as spam. Even trying to add myself to cc takes me to an 
error page.

I got the following message when I last tried to modify a ticket. I was 
changing the summary of one of the tickets:

>
>
> Submission rejected as potential spam
>
>- Akismet says content is spam
>
>
>- SpamBayes determined spam probability of 93.46%
>
>
I sometimes also get a page with a captcha but without a submit button and 
it redirects me to another TracError page if I submit it anyways by 
pressing the return key.


Please take the necessary steps to mitigate this problem and let me know if 
there is something I could help with.

Thanks

On Thursday, 7 July 2016 08:03:54 UTC+5:30, Tim Graham wrote:
>
> In the past couple hours, code.djangoproject.com experienced a spam 
> attack of new tickets and wiki pages. After running without the spam filter 
> for at least a couple months (I forget exactly when I deactivated it but it 
> was sometime after we switched to requiring authenticated users to file a 
> ticket), I've reactivated it. If you find your submissions inappropriately 
> marked as spam, let me know so we can tune the settings.
>

-- 
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/deedad00-3ba7-4da3-ad9b-5c98efd82f02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trac spam attack / spam filter reactivated

[akki]

This might be a quite obvious solution but people seem to be happy with the 
performance of Bayesian filter when training it properly. Here are two 
articles I found explaining some good points to keep in mind while training 
the filter - edgewall-ticket-10314 <https://trac.edgewall.org/ticket/10314>
 and trac-wiki-spamfilters <https://trac.edgewall.org/wiki/SpamFilter#Bayes>; 
just wanted to make sure we are not being bitten due to bad training.

Also, if the spammers, assuming they are bots, are able to solve recaptcha, 
we can try keycaptchas <https://trac.edgewall.org/wiki/SpamFilter#Captcha> 
supported 
by Trac which are relatively harder to solve. If they are being hit 
manually by someone, the ip-throttling 
<https://trac.edgewall.org/wiki/SpamFilter#IPThrottling> technique might 
tackle such a situation (but then they'll use proxies, sigh!).

Well, this is a tricky experimenting business but I hope something out of 
this works.


On Saturday, 6 August 2016 18:26:34 UTC+5:30, Tim Graham wrote:
>
> Yes, the bayesian spam filter is giving some false positives and the 
> weighting is such that even if you submit the captcha, your comment still 
> might be considered spam (spammers were completing the captchas to submit 
> their content). You could look into if there's some other spam prevention 
> measures in Trac that might be more effective.
>
> On Saturday, August 6, 2016 at 7:55:18 AM UTC-4, akki wrote:
>>
>> Hi
>>
>> Recently, I would say since the past week, many of my activities on Trac 
>> are being reported as spam. Even trying to add myself to cc takes me to an 
>> error page.
>>
>> I got the following message when I last tried to modify a ticket. I was 
>> changing the summary of one of the tickets:
>>
>>>
>>>
>>> Submission rejected as potential spam
>>>
>>>- Akismet says content is spam
>>>
>>>
>>>- SpamBayes determined spam probability of 93.46%
>>>
>>>
>> I sometimes also get a page with a captcha but without a submit button 
>> and it redirects me to another TracError page if I submit it anyways by 
>> pressing the return key.
>>
>>
>> Please take the necessary steps to mitigate this problem and let me know 
>> if there is something I could help with.
>>
>> Thanks
>>
>> On Thursday, 7 July 2016 08:03:54 UTC+5:30, Tim Graham wrote:
>>>
>>> In the past couple hours, code.djangoproject.com experienced a spam 
>>> attack of new tickets and wiki pages. After running without the spam filter 
>>> for at least a couple months (I forget exactly when I deactivated it but it 
>>> was sometime after we switched to requiring authenticated users to file a 
>>> ticket), I've reactivated it. If you find your submissions inappropriately 
>>> marked as spam, let me know so we can tune the settings.
>>>
>>

-- 
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/a359b711-8101-46ca-a91d-ae1b59cf7997%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Introduce Meta.indexes - !6857 
   <https://github.com/django/django/pull/6857>, #26808 
   <https://code.djangoproject.com/ticket/26808>
   The PR <https://github.com/django/django/pull/6857> has been merged. Now 
   class based indexes can be added using Meta.indexes 
   
<https://docs.djangoproject.com/en/dev/ref/models/options/#django.db.models.Options.indexes>
   .
   
   - Add support for column ordering (ASC/DESC) in class based indexes - 
   !6982 <https://github.com/django/django/pull/6982>, #20888 
   <https://code.djangoproject.com/ticket/20888/>
   Resolve test failures on Oracle
   Update according to review suggestions
   
   - Resolve bug when unique_together was dropped along with it's field - 
   #26180 <https://code.djangoproject.com/ticket/26180>
   Solve with another approach by introducing *[Add|Remove]UniqueTogether* 
   operations and removing *generate_altered_unique_together* method of 
   *migrations.Autodetector*
   PR - https://github.com/django/django/pull/7038
   
   - Add support for GIN indexes
   Add *BtreeGinExtension* operation to *contrib.postgres* to create 
   btree_gin extension
   Add *GinIndex* to *contrib.postgres.indexes*
   Ticket - https://code.djangoproject.com/ticket/27030
   PR - https://github.com/django/django/pull/7046
   


On Tuesday, 2 August 2016 11:12:27 UTC+5:30, akki wrote:
>
>
>
>- Add support for column ordering (ASC/DESC) in class based indexes
>Completed - tests, docs, code
>PR - https://github.com/django/django/pull/6982
>
>- Implement Hash index class
>Add capability to get type of index in introspection (required for 
>testing this feature)
>Completed - Add tests, docs, code
>PR - https://github.com/django/django/pull/6995
>Ticket - https://code.djangoproject.com/ticket/26974
>
>- Some minor changes in !6857 
><https://github.com/django/django/pull/6857>
>
> Other than these, I also had a look at btree_gin indexes and extensions 
> but haven't started the implementation yet.
>
> On Wednesday, 27 July 2016 20:26:38 UTC+5:30, akki wrote:
>>
>> Hi Jani
>>
>> Thanks a lot for offering help. I did face some issues with the Oracle 
>> setup in the beginning but was able to resolve them yesterday. :)
>> You are most welcomed to review the PR and offer any suggestions for 
>> improvement at https://github.com/django/django/pull/6982/. The work 
>> related to the feature is in progress but the introspection-related work is 
>> mostly complete.
>>
>> Regards
>> Akshesh(akki)
>>
>> On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:
>>>
>>> Hi,
>>>
>>> On 26.07.2016 04:28, akki wrote:
>>>
>>>
>>>
>>>- Fixed #24442 <http://code.djangoproject.com/ticket/24442> - 
>>>Improved schema's index name creating algorithm
>>>Updated !6898 <http://github.com/django/django/pull/6898> to take 
>>>    all column names into account while creating index name 
>>>
>>>
>>>- Add support for column ordering (ASC/DESC) in class based indexes
>>>Somewhat provides the feature requested in #20888 
>>><https://code.djangoproject.com/ticket/20888#comment:10>
>>>WIP code on my branch - 
>>>https://github.com/akki/django/commits/gsoc-indexes-order
>>>Modifying introspection of all databases to return column order as 
>>>well (required for testing) -- implementation for Oracle remaining.
>>>
>>>
>>> If you get stuck with Oracle I can lend a hand to help to figure out the 
>>> details.
>>>
>>>
>>>- Implement Hash index class
>>>WIP implementation at 
>>>https://github.com/akki/django/commits/gsoc-indexes-hash
>>>Currently implemented only for postgresql because that's the only 
>>>backend which fully supports it AFAIK (MySQL supports for some storage 
>>>engines but neither for MyISAM nor InnoDB). 
>>>
>>>
>>> On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote: 
>>>>
>>>>
>>>>- Introduce Meta.indexes
>>>>PR - https://github.com/django/django/pull/6857.
>>>>Ticket - https://code.djangoproject.com/ticket/26808.
>>>>Made a design change so that index can drop it's model attribute by 
>>>>introducing *Index.set_name_with_model* method
>>>>Wrote some left out tests for *related_dependencies*.
>>>>
>>>>- Fixed #24442 <https://code.djangoproject.com/t

Re: Google Summer of Code Updates - Class based indexes

[akki]

   
   - Add support for column ordering (ASC/DESC) in class based indexes - 
   !6982 <https://github.com/django/django/pull/6982>, #20888 
   <https://code.djangoproject.com/ticket/20888/>
   The PR has been merged. More on using it over here 
   <https://docs.djangoproject.com/en/dev/ref/models/indexes/#fields>.
   
   - Resolve bug when unique_together was dropped along with it's field - 
   !7038 <https://github.com/django/django/pull/7038>, #26180 
   <https://code.djangoproject.com/ticket/26180>
   Added tests for the new operation. WIP.
   
   - Add support for GIN indexes - !7046 
   <https://github.com/django/django/pull/7046>, #27030 
   <https://code.djangoproject.com/ticket/27030>
   You can use GIN indexes now using the new GinIndex 
   
<https://docs.djangoproject.com/en/dev/ref/contrib/postgres/indexes/#ginindex> 
index 
   class (and install btree_gin extension using the BtreeGinExtension 
   
<https://docs.djangoproject.com/en/dev/ref/contrib/postgres/operations/#btreeginextension>
 
   operation, if required.)
   
   - Take indexes into account in inspectdb command
   Updated/completed earlier code
   Ticket - https://code.djangoproject.com/ticket/27060
   PR - https://github.com/django/django/pull/7083
   
   
   

On Tuesday, 9 August 2016 01:30:54 UTC+5:30, akki wrote:
>
>
>- Introduce Meta.indexes - !6857 
><https://github.com/django/django/pull/6857>, #26808 
><https://code.djangoproject.com/ticket/26808>
>The PR <https://github.com/django/django/pull/6857> has been merged. 
>Now class based indexes can be added using Meta.indexes 
>
> <https://docs.djangoproject.com/en/dev/ref/models/options/#django.db.models.Options.indexes>
>.
>
>- Add support for column ordering (ASC/DESC) in class based indexes - 
>!6982 <https://github.com/django/django/pull/6982>, #20888 
><https://code.djangoproject.com/ticket/20888/>
>Resolve test failures on Oracle
>Update according to review suggestions
>
>- Resolve bug when unique_together was dropped along with it's field - 
>#26180 <https://code.djangoproject.com/ticket/26180>
>Solve with another approach by introducing *[Add|Remove]UniqueTogether* 
>operations and removing *generate_altered_unique_together* method of 
>*migrations.Autodetector*
>PR - https://github.com/django/django/pull/7038
>
>- Add support for GIN indexes
>Add *BtreeGinExtension* operation to *contrib.postgres* to create 
>btree_gin extension
>Add *GinIndex* to *contrib.postgres.indexes*
>Ticket - https://code.djangoproject.com/ticket/27030
>PR - https://github.com/django/django/pull/7046
>
>
>
> On Tuesday, 2 August 2016 11:12:27 UTC+5:30, akki wrote:
>>
>>
>>
>>- Add support for column ordering (ASC/DESC) in class based indexes
>>Completed - tests, docs, code
>>PR - https://github.com/django/django/pull/6982
>>
>>- Implement Hash index class
>>Add capability to get type of index in introspection (required for 
>>testing this feature)
>>Completed - Add tests, docs, code
>>PR - https://github.com/django/django/pull/6995
>>Ticket - https://code.djangoproject.com/ticket/26974
>>
>>- Some minor changes in !6857 
>><https://github.com/django/django/pull/6857>
>>
>> Other than these, I also had a look at btree_gin indexes and extensions 
>> but haven't started the implementation yet.
>>
>> On Wednesday, 27 July 2016 20:26:38 UTC+5:30, akki wrote:
>>>
>>> Hi Jani
>>>
>>> Thanks a lot for offering help. I did face some issues with the Oracle 
>>> setup in the beginning but was able to resolve them yesterday. :)
>>> You are most welcomed to review the PR and offer any suggestions for 
>>> improvement at https://github.com/django/django/pull/6982/. The work 
>>> related to the feature is in progress but the introspection-related work is 
>>> mostly complete.
>>>
>>> Regards
>>> Akshesh(akki)
>>>
>>> On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 26.07.2016 04:28, akki wrote:
>>>>
>>>>
>>>>
>>>>- Fixed #24442 <http://code.djangoproject.com/ticket/24442> - 
>>>>Improved schema's index name creating algorithm
>>>>Updated !6898 <http://github.com/django/django/pull/6898> to take 
>>>>all column names into account while creating index name 
>>>>
>>

Take index type into account in inspectdb command

[akki]

Hi

Currently the inspectdb command doesn't take the database indexes into 
account (Ticket - #27060 
<https://code.djangoproject.com/ticket/27060#ticket>). While working on 
adding this feature, there was some confusion related to the inclusion of 
the index type.


I have implemented this feature here 
<https://github.com/django/django/pull/7083> but since Django doesn't 
support introspection of the type of index, currently the generated models 
have the default (B-tree) index no matter what the type of the actual index 
in the database may be. So I would like seek some advice on whether it 
would be a good idea to move ahead with this approach with a comment at the 
beginning of the generated file with the other comments 
<https://github.com/django/django/blob/19e20a2a3f763388bba9263d56db34012e90cf5b/django/core/management/commands/inspectdb.py#L48>
 and 
integrate this basic implementation into Django (with an update on the 
ticket and keeping the ticket open, maybe?).

Or should this be kept on a hold until Django supports introspection of the 
index type for it's backends (PostgreSQL has this feature with some concerns 
about the design 
<https://github.com/django/django/pull/7046#discussion-diff-74431956>) and 
be done correctly all at once. Once that happens we would either use the 
correct index type if it is supported by Django, else add a comment 
informing that the index type is not a match and should be created manually.


Please let me know if any other clarification is required on this. Thanks 
for any help.

Regards
akki

-- 
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/28795bda-263b-4d6b-9c04-b5790adba868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

Hi

The GSoC 2016 period has almost reached it's completion and I have 
completed my submission. You can find my work submission here 
- https://gist.github.com/akki/f45c7cf5db30c025f49d862d82dd259a.

I enjoyed a lot working on this project and am very excited about everyone 
making use of class based indexes. There is some work 
<https://code.djangoproject.com/ticket/27097> remaining which would be 
helpful to extend support for other index types and add new index classes. 
I will continue working on it and try to finish it soon. Meanwhile, you can 
use the current indexes from the master repo i.e. development version (and 
report bugs/provide feedback).

Many thanks to everyone for their involvement and valuable suggestions 
throughout the summer. :)

Cheers
akki

On Tuesday, 16 August 2016 18:16:22 UTC+5:30, thinkwel...@gmail.com wrote:
>
> Thank you, akki, for this project! Have enjoyed following your progress. 
> It'll be something I'm going to make significant use of.
>

-- 
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/ba544784-3512-47ef-a045-bdcfd3adb222%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[akki]

Thanks a lot Josh! Actually it was this mail 
<https://groups.google.com/d/msg/django-developers/3c8AvB3X6mk/gbkbbwEuCAAJ> 
sent by you that made me interested in this idea and later take it up as a 
project for GSoC, so a big THANK YOU to you. :)


Great work, akki!
>
>
> I think you should add it to 1.11 Changelog 
> <https://www.google.com/url?q=https%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Freleases%2F1.11%2F&sa=D&sntz=1&usg=AFQjCNGHasD90_GShNFLPljppo9QpfQvaQ>
>  as 
> major new feature, and add yourself to authors 
> <https://github.com/django/django/blob/master/AUTHORS> list as well. 
>
 
>
Thanks. I have sent a PR to add it to the release docs, you can have a look 
at it at https://github.com/django/django/pull/7144.

-- 
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/c5f358c5-ed08-4f03-9e8c-61ea71b42930%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Take index type into account in inspectdb command

[akki]

Ticket to add support for introspection of index type 
- https://code.djangoproject.com/ticket/27097



On Friday, 19 August 2016 21:03:00 UTC+5:30, Tim Graham wrote:
>
> I think if we do a similar thing like we do for field introspection 
> (outputting a comment like "# This field type is a guess" next to unknown 
> fields) it would be okay. The comment might say the backend doesn't support 
> index type introspection. Let's put out a call for help to try to get index 
> introspection done on the other databases for 1.11.
>
> On Wednesday, August 17, 2016 at 12:01:51 PM UTC-4, akki wrote:
>>
>> Hi
>>
>> Currently the inspectdb command doesn't take the database indexes into 
>> account (Ticket - #27060 
>> <https://code.djangoproject.com/ticket/27060#ticket>). While working on 
>> adding this feature, there was some confusion related to the inclusion of 
>> the index type.
>>
>>
>> I have implemented this feature here 
>> <https://github.com/django/django/pull/7083> but since Django doesn't 
>> support introspection of the type of index, currently the generated models 
>> have the default (B-tree) index no matter what the type of the actual index 
>> in the database may be. So I would like seek some advice on whether it 
>> would be a good idea to move ahead with this approach with a comment at the 
>> beginning of the generated file with the other comments 
>> <https://github.com/django/django/blob/19e20a2a3f763388bba9263d56db34012e90cf5b/django/core/management/commands/inspectdb.py#L48>
>>  and 
>> integrate this basic implementation into Django (with an update on the 
>> ticket and keeping the ticket open, maybe?).
>>
>> Or should this be kept on a hold until Django supports introspection of 
>> the index type for it's backends (PostgreSQL has this feature with some 
>> concerns 
>> about the design 
>> <https://github.com/django/django/pull/7046#discussion-diff-74431956>) 
>> and be done correctly all at once. Once that happens we would either use 
>> the correct index type if it is supported by Django, else add a comment 
>> informing that the index type is not a match and should be created manually.
>>
>>
>> Please let me know if any other clarification is required on this. Thanks 
>> for any help.
>>
>> Regards
>> akki
>>
>

-- 
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/4f7e7d3a-77d2-4a11-aab1-568e1a0352b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Project idea for GSoC page - Support for expressions in indexes

[akki]

Hi

This is in regards of this thread that was posted a few days back - 
https://groups.google.com/forum/#!topic/django-developers/8qvrKfZaP2o

I think "extending support for expressions into indexes" would make a good 
candidate for the ideas page. This post 
 by 
Josh mentions steps to be followed to accomplish this task in a nutshell 
(1st point had been completed in last year's GSoC). The ticket for the same 
is https://code.djangoproject.com/ticket/26167.
For the complexity of this task I would suggest that it's between 
medium-hard as it requires good knowledge about how both expressions and 
class based indexes work in Django.
As far as mentoring the project is concerned I am currently not in a 
situation to state if I'll be free for the task after a couple of months so 
can't commit on that right now. I'll definitely help out the student with 
any queries if anyone does pick up this project this year.

-- 
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/5eb993a9-1929-4f58-b286-2482ab357f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2017

[akki]

I have posted a project idea here - 
https://groups.google.com/forum/#!topic/django-developers/QXYalFV90UU.

On Saturday, 21 January 2017 02:27:33 UTC+5:30, Tim Graham wrote:
>
> I've submitted our organization application for this year.
>
> Anyone interested in mentoring, please indicate your interest 
> https://code.djangoproject.com/wiki/SummerOfCode2017. Any experienced 
> contributors are welcome to mentor. We also need project ideas on that 
> page. I've copied the ideas from past years, but they may not be the best. 
> If you have an idea in mind, feel free to start a new thread on this 
> mailing list to see if others think it's suitable.
>
> Any students interested in participating, the time to starting 
> contributing is now! The chances of developing a successful proposal 
> without any past contributions to Django is very low.
>
> If you have a question, let me know.
>

-- 
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/5fc42bf2-ad0d-442f-bbec-d584dc6c2faa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Project idea for GSoC page - Support for expressions in indexes

[akki]

@Josh Absolutely correct. I meant since this involves a lot of things (a 
couple of them are listed by Markus on the ticket itself) to do, they can 
use a helping hand from a student developing full-time.
It's just a suggestion of mine, they are doing an incredible job and it's 
totally their call (they can mentor the project as well since they have 
already come so far with the ticket). :)

Other than that there are many more things related to indexes that are 
remaining like implementing a RenameIndex migration operation 
<https://code.djangoproject.com/ticket/27064>, making db_index use class 
based indexes under the hood (2nd point of the post mentioned in my last 
mail), deprecating index_together 
<https://code.djangoproject.com/ticket/27236>, bring indexes under inspectdb 
<https://code.djangoproject.com/ticket/27060>, etc. which the students can 
involve in there project. There are even more things to do related to 
db-indexes than these, checkout the tickets having "db-indexes" in their 
keywords 
<https://code.djangoproject.com/query?status=assigned&status=new&keywords=~db-index&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id>
 
for them.

This project can be thought more of getting "Django indexes into Spartan 
mode" than just "extending expressions into indexes" as I had called it 
earlier, as it would power Django to do much more with indexes via class 
based indexes. So if it looks good to the community this can be included in 
the ideas page of Django's GSoC page.

On Saturday, 4 March 2017 07:33:57 UTC+5:30, Josh Smeaton wrote:

> I think Markus is currently working on this idea, along with Ian Foote, 
> who has contributed some precursor work to make the idea possible 
> (deconstructed expressions). The current PR is 
> https://github.com/django/django/pull/8056
>
> On Saturday, 4 March 2017 05:39:11 UTC+11, akki wrote:
>>
>> Hi
>>
>> This is in regards of this thread that was posted a few days back - 
>> https://groups.google.com/forum/#!topic/django-developers/8qvrKfZaP2o
>>
>> I think "extending support for expressions into indexes" would make a 
>> good candidate for the ideas page. This post 
>> <https://groups.google.com/d/msg/django-developers/3c8AvB3X6mk/gbkbbwEuCAAJ> 
>> by 
>> Josh mentions steps to be followed to accomplish this task in a nutshell 
>> (1st point had been completed in last year's GSoC). The ticket for the same 
>> is https://code.djangoproject.com/ticket/26167.
>> For the complexity of this task I would suggest that it's between 
>> medium-hard as it requires good knowledge about how both expressions and 
>> class based indexes work in Django.
>> As far as mentoring the project is concerned I am currently not in a 
>> situation to state if I'll be free for the task after a couple of months so 
>> can't commit on that right now. I'll definitely help out the student with 
>> any queries if anyone does pick up this project this year.
>>
>>

-- 
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/089d838b-4bd1-42bd-bd28-e1d18ac0cfa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Project idea for GSoC page - Support for expressions in indexes

[akki]

On Saturday, 4 March 2017 17:42:26 UTC+5:30, Florian Apolloner wrote:
>
> On Saturday, March 4, 2017 at 6:52:01 AM UTC+1, akki wrote:
>>
>> @Josh Absolutely correct. I meant since this involves a lot of things (a 
>> couple of them are listed by Markus on the ticket itself) to do, they can 
>> use a helping hand from a student developing full-time.
>>
>
> The GSoC program does not allow for something like that. If that would 
> happen Markus and Ian would be required to put their hands down and do 
> nothing basically.
>

First of all let's not call the work done by the 1000s of GSoC mentors 
every year "putting down hands and doing nothing".
Second of all, since Markus and Ian are actively working on this task and 
there is not requirement of more help to complete it, I (undoubtedly) take 
back this suggestion of mine.
Lastly, if there is no work going on by anybody on the other tickets that I 
mentioned earlier (2nd paragraph of my last mail), I think they can be 
added to the ideas page with everyone's consent.

-- 
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/37eac965-5b8f-46ab-a4de-b31b446446d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Project idea for GSoC page - Support for expressions in indexes

[akki]

On Sunday, 5 March 2017 01:53:28 UTC+5:30, Florian Apolloner wrote:
>
> On Saturday, March 4, 2017 at 7:10:57 PM UTC+1, akki wrote:
>>
>> First of all let's not call the work done by the 1000s of GSoC mentors 
>> every year "putting down hands and doing nothing".
>>
>
> I am pretty sure I did not say that
>
Thanks!

What do you think about the other tasks? Is it all right to include them on 
the page?

-- 
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/6fac2990-8c55-4e66-bf81-38541df38f7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.