Re: Google Summer of Code Updates - Class based indexes

[akki]

   - Fixed #24442  - Improved 
   schema's index name creating algorithm
   Updated !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 
   
   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  - Improve 
>schema's index name creating algorithm
>PR  - https://github.com/django/django/pull/6898 
>
>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  accordingly.
>
>
> On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote:
>>
>>
>>- Restructure index migrations - Polished according to all reviews, 
>>the PR  has been merged.
>>- Introduce Meta.indexes - Updated PR 
>> according to suggestions 
>>as per reviews.
>>- Improve schema's index name creating algorithm - #24442 
>> !6898 
>>.
>>- Add support for indexes to inspectdb - This depends on !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/be05e9f0-ed44-4c73-aa41-b02349584e29%40googlegroups.com.
For more options, visit 

Re: Proposal: Use HTML5 boolean attribute for checked on checkbox/radio inputs

[Jon Dufresne]

> I was wondering if it causes any HTML validation problems for other
doctypes?

True. A strict validator for XHTML will flag HTML5 syntax as an error. It
isn't a part of the XHTML spec. From my testing it seems like modern
browsers can handle this, but you're right, validators will catch it.

> If so, we might document that Django's default HTML rendering targets the
HTML5 doctype.

Makes sense to me. I've updated PR with additional documentation that
mentions this.

Cheers,
Jon

-- 
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/CADhq2b5UsjaAKQhe%2Bn0eYabCuBPTG-72RvYEHz1dC7oZgefvGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub PR status within Trac

[Tim Graham]

If the goal is to provide a list of issues suitable for new contributors, I 
think a curated list of tickets is likely more useful than trying to 
automate something. Looking over the list of "Has patch" + "Needs 
improvement" tickets, it seems to me that most of those PRs fizzled out for 
non-trivial reasons. Going forward, I'll check "Easy pickings" on tickets 
where I close the PR due to inactivity and where only straightforward 
updates remain.

On Friday, July 22, 2016 at 7:13:52 PM UTC-4, Carl Meyer wrote:
>
> Hi Tobias, 
>
> On 07/22/2016 04:53 PM, Tobias McNulty wrote: 
> > I spent some time during the DjangoCon sprint today looking into 
> > dashboard.djangoproject.com  and 
> how 
> > it calculates metrics. I was hoping to add some new metrics that mash up 
> > data from GitHub and Trac together. While technically possible, this 
> > breaks down when you want to link out to a list of the related tickets 
> > in Trac. For example: 
> > 
> >   * A list of Accepted tickets with no open PR or an open PR that hasn't 
> > t been touched in X months 
> >   * A list of Accepted tickets with no PR and no attached patch that 
> > haven't been touched in  months 
> > 
> > This got me wondering: Is checking for GitHub PRs via JavaScript the 
> > Right Way to do it? What if we had a cronjob update Trac periodically 
> > with PR status from GitHub? 
> > 
> > I think it would be valuable to be able to query on PR status from 
> > within Trac, e.g., to help find in progress but stale/abandoned tickets. 
> > Cleaning up the work of someone else who's lost interest in a patch is 
> > often a good way to get into Django development. 
> > 
> > I'm sure there are some holes in this idea, so I'm putting it out there 
> > for comment. Was something like this considered before, and if so, why 
> > wasn't it pursued? 
> > 
> > If it hasn't been considered before, what are the obvious problems I 
> > might encounter? 
>
> Others know these systems better than I do, but just a couple thoughts: 
>
> 1) While being able to query Trac by PR status would be useful, losing 
> the immediate feedback of "I just created my PR and reloaded the Trac 
> ticket, and there it is!" would be a significant loss, I think. Delays, 
> even of just a few minutes, in that sort of UI tend to introduce an "is 
> this actually working" uncertainty that leads to extra support queries. 
> So maybe even if you implemented something on the backend, we shouldn't 
> get rid of the JS code? Or maybe github push hooks could be used to keep 
> update latency low? 
>
> 2) I think it was done this way originally because whoever did it was 
> scared of touching Trac's Python code (with reason), and it was simpler 
> to just do it in JS, not for any deeper reason. 
>
> Carl 
>
>

-- 
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/8c220d4c-b2fb-46cc-b207-b75b14ee3e8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Use HTML5 boolean attribute for checked on checkbox/radio inputs

[Tim Graham]

I was wondering if it causes any HTML validation problems for other 
doctypes? If so, we might document that Django's default HTML rendering 
targets the HTML5 doctype.

On Saturday, July 23, 2016 at 4:21:22 AM UTC-4, Florian Apolloner wrote:
>
> This should be perfectly fine -- I guess just nobody got around to do it 
> yet. The main issue with the HTML5 stuff is around date where it is 
> not clearly specified (or was last time I looked) what the UA should send 
> and how to handle that in browsers not supporting HTML5 yet (ie sending iso 
> date/time is not so nice when you want to display it localized). The 
> required attribute was also problematic in the sense that now hidden 
> (unused) forms with required would prevent the page from validating etc… So 
> any change like yours currently, which does not introduce such issues 
> should be no problem.
>
> Cheers,
> Florian
>
> On Friday, July 22, 2016 at 11:30:58 PM UTC+2, Jon Dufresne wrote:
>>
>> Hi,
>>
>> I would like to propose that Django renders the "checked" attribute of 
>> checkbox and radio inputs using the HTML5 boolean style attributes.
>>
>> Django has supported HTML5 boolean attributes since 1.8 [0]. It has used 
>> them internally for the "disabled" attribute since 1.9 [1] and the 
>> "required" attribute starting with 1.10 [2]. So there is some precedent to 
>> using the HTML5 style. I find the newer style cleaner and more in line with 
>> modern conventions.
>>
>> I have created a ticket [3] with this proposal as well as a PR [4].
>>
>> One concern raised in the ticket is backwards compatibility with 
>> non-HTML5 doctypes. I'm not aware of any such issues with modern browsers. 
>> I have tested older doctypes on Firefox and Chrome, both accept the HTML5 
>> boolean style with HTML4 and XHTML doctypes. Currently, I do not have 
>> access to IE, so I am unable to test those cases. If anyone is interested 
>> to test, there is a very simple test case in the ticket.
>>
>> Additionally, if there is an issue with older doctypes, presumably this 
>> issue already exists with the disabled and required attributes.
>>
>> Just reaching out for feedback, concerns, and comments.
>>
>> Thanks!
>>
>> Cheers,
>> Jon
>>
>>
>> [0] https://docs.djangoproject.com/en/dev/releases/1.8/#forms
>> [1] 
>> https://github.com/django/django/blob/stable/1.9.x/django/forms/boundfield.py#L88-L89
>> [2] 
>> https://github.com/django/django/blob/stable/1.10.x/django/forms/boundfield.py#L88-L89
>> [3] Ticket: https://code.djangoproject.com/ticket/26928
>> [4] PR: https://github.com/django/django/pull/6961
>>
>>

-- 
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/fbf8f4be-d7cf-495d-9754-dc5c0e54f962%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - July 23, 2016

[Tim Graham]

I enjoyed meeting many people from the community at DjangoCon US last week. 
We had about 20-30 people sprinting on Django on Thursday and Friday. Only 
a couple had contributed to Django before.

Triaged

---

https://code.djangoproject.com/ticket/26899 - Document why RawSQL requires 
parameters (accepted)

https://code.djangoproject.com/ticket/26914 - Invalid characters in cookie 
name breaks csrf checking (duplicate)

https://code.djangoproject.com/ticket/26911 - RedirectView failing silently 
on NoReverseMatch is confusing (accepted)

https://code.djangoproject.com/ticket/26917 - Disabled ModelChoiceFields 
crash in Django 1.10 (accepted)

https://code.djangoproject.com/ticket/26896 - FileSystemStorage no longer 
accepts reverse_lazy as base_url (accepted)

https://code.djangoproject.com/ticket/26930 - makemigrations tries to 
access default databases even when set to empty (accepted)

https://code.djangoproject.com/ticket/26925 - Add a link to aggregation 
ordering interaction from Meta.ordering docs (fixed)

https://code.djangoproject.com/ticket/26934 - Admin inline save fails when 
inline contains readonly primary key (duplicate)

Authored



https://github.com/django/django/pull/6929 - Fixed #26908 -- Fixed crash 
with jsonfield__key__isnull lookup.

https://github.com/django/django/pull/6935 - Fixed a GeoIP test failure 
with the latest data.
https://github.com/django/django/commit/93c538694e6b14a29cb0f52b784a3bfed604fda6
 
- Fixed XSS in admin's add/change related popup.

Reviewed/committed

--

https://github.com/django/django/pull/6807 - Fixed #22446 -- Added tox.ini 
to automate pull request checks.

https://github.com/django/django/pull/6943 - Fixed #26922 -- Fixed 
SimpleTestCase.assertHTMLEqual() crash on Python 3.5.

https://github.com/django/django/pull/6950 - Refs #26796 -- Fixed 
ManyToManyField's limit_choices_to warning without a through model.

https://github.com/django/django/pull/6952 - Fixed #18348 -- Documented 
SesssionStore.create()

Reviews of core dev work


https://github.com/django/django/pull/6936 - Fixed #26916 -- Fixed 
prefetch_related when using a cached_property as to_attr.

-- 
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/debe7dca-dfae-413a-9c63-70f996255395%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.