Re: GSOC 2015: Improving the less popular database backends

2015-03-09 Thread Yichun Duan
Thanks a lot for your suggestions. I'll try.

在 2015年3月10日星期二 UTC+8上午8:10:49,Russell Keith-Magee写道:
>
> Hi Yichun,
>
> On Mon, Mar 9, 2015 at 4:13 PM, Yichun Duan  > wrote:
>
>> Hi,
>>
>> I'm Yichun and I'm interested in the Project ' Improving the less 
>> popular database backends' in GSOC 2015. I major in computer science in 
>> Peking University. I've worked with C++, Java, Python and I've written 
>> several webapps using Django. 
>>
>> I have some questions related to this project and your answers will be of 
>> big help.
>>
>> (1) I'd like to make sure that I've understood this project in a right 
>> way. For example, if I choose to improve the backend of Oracle, then I can 
>> choose some related issues in Trac's list of Oracle issues 
>> 
>>  and 
>> prepare to work on them during the whole term, right? I've not seen a 
>> mentor for this project in the GSOC guide, and I think someone here may 
>> help me.
>>
>
> I don't think anyone has specifically stepped forward to mentor an 
> Oracle-based project, but if you put forward a strong proposal, we will 
> find someone to mentor you. 
>
> As for what to tackle for the project itself - one approach for your 
> project would be to just tackle a collection of Oracle-related tickets. A 
> better approach (more likely to be accepted) would be for your to analyse 
> the tickets that have been reported, and see if you can find a common theme 
> (or themes) - and then propose a way that we can eliminate those problems 
> at a higher level.
>  
>
>> (2) Actually I'm familiar with MySQL and SqlServer, but never use Oracle 
>> before. Will it be a big obstacle in my work if I choose to write the 
>> backend of Oracle? Or if I begin studying Oracle right now, it won't be a 
>> problem?
>>
>
> A history of Oracle experience would definitely work in your favour, but 
> *not* having that experience won't necessarily work against you. The fact 
> that you've got experience with multiple SQL flavours means you should be 
> aware of some of the interesting ways SQL is interpreted. Highlight that 
> experience in your application, and that should be enough.
>
> Alternatively, you could try to work with the developers of the SQLServer 
> backend and see if you could improve support for that backend.
>  
>
>> (3) I'm a new contributor in Django. Before I start working on my 
>> project, should I start from fix simple bugs or something else?
>>
>  
> You don't have to, but it would certainly be looked upon favourably. In 
> particular, if you were to tackle one or two small Oracle bugs, that would 
> be very helpful to prove that you're going to be able to quickly pick up 
> the new skills you require for the GSoC term.
>
> Yours,
> Russ Magee %-)
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f99fd9b7-4eb5-412b-88b8-6adb1c36e1a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Password validation in Django revisited

2015-03-09 Thread Collin Anderson
Hi Erik,

This nice, though I'd like it even more if it didn't introduce another 
setting. :) Having it on the backend would solve that problem for me I 
think.

Also, this may be obvious, but more specific error messages would be nice, 
like "password is too simliar to username".

Collin

On Monday, March 9, 2015 at 5:43:36 PM UTC-4, Aymeric Augustin wrote:
>
> Hi Erik, 
>
> Great work! 
>
> Did you consider tying validators to authentication backends? I admit it 
> sounds like a bad idea and most likely it is, but since different backends 
> may have different security requirements, I'd like to make sure we aren't 
> missing something. 
>
> Assuming help_text is HTML, you may improve it by building it as follows: 
>
> Your password must match the following requirements: 
>  
> validator 1's requirements 
> ... 
>  
>
> This version looks slightly worse when there's only one validator. However 
> I expect most sites will use at least two or three validators: minimum 
> length, character classes (lower/upper/figures), not a common password (we 
> should ship a static blacklist of the top 100 most common passwords, 
> there's tons of research on this). 
>
> In order to prevent reuse of old passwords, you need to add another method 
> to the validator class that is called after the password is successfully 
> changed. Otherwise, if the user submits a password change form and the new 
> password goes through the validators successfully but the submission fails 
> for some other reason (e.g. the current password is wrong), then the user 
> can't re-submit the same new password, even though they never used it. 
>
> -- 
> Aymeric. 
>
> > Le 8 mars 2015 à 15:47, Erik Romijn  
> a écrit : 
> > 
> > Hello all, 
> > 
> > I've taken another stab at 16860[1]: having a password validation/policy 
> in Django. I've made an initial simple PR[2] to show the approach I'd like 
> to use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, 
> influencing the later possibilities, which I'll try to outline below. 
> > 
> > Users choosing awful passwords is a serious security issue. Although 
> password validation can only go so far - especially to the extent that we 
> can implement in Django itself - to me it seems part of our responsibility 
> in helping Django developers to build safer websites. 
> > 
> > First, let me briefly describe my approach: we add a new setting to 
> define zero or more password validator classes. Optionally, a class can be 
> provided with custom arguments to it's constructor. Each validator class 
> has a help_text() method and a validate(password, user) method. The former 
> produces a translatable sentence to be included in the form field's help 
> text. The validate method validates a certain password, optionally taking 
> the context of a user into account and passes its judgement on the 
> password. If a validator considers a password insufficient, it raises a 
> ValidationError. 
> > 
> > This is tied to the validation and form field setup in SetPasswordForm 
> and AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as 
> I feel this validation should primarily take place on the user frontend 
> site with forms. This mirrors the way we typically handle this in Django. 
> Should someone feel different, and want to tie this to set_password() as 
> well, this is possible with a custom user object. Tying this validation 
> into any other place is also trivial: just adding a single line. 
> > 
> > I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised 
> in previous discussions on this issue. 
> > 
> > In the ticket, Shai described a few particular goals for this feature: 
> > 
> > - Informing the user of the various password requirements: this is 
> possible by each validator providing a description, which can be dependent 
> on it's configuration, of it's requirements. Independent sentences from 
> different validators are now concatenated, an approach which will not 
> always yield the prettiest language. 
> > - Allowing policies to chain together smoothly: multiple validators can 
> be run sequentially, stopping after the first failure. 
> > - Provide flexibility for complex requirements (some may include their 
> own models): this is entirely possible within the design. 
> > - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template. 
> > - Javascript validation assistance or HTML5 support: not implemented 
> currently, but this could be added in a similar 

Re: GSOC 2015: Improving the less popular database backends

2015-03-09 Thread Russell Keith-Magee
Hi Yichun,

On Mon, Mar 9, 2015 at 4:13 PM, Yichun Duan  wrote:

> Hi,
>
> I'm Yichun and I'm interested in the Project ' Improving the less popular
> database backends' in GSOC 2015. I major in computer science in Peking
> University. I've worked with C++, Java, Python and I've written several
> webapps using Django.
>
> I have some questions related to this project and your answers will be of
> big help.
>
> (1) I'd like to make sure that I've understood this project in a right
> way. For example, if I choose to improve the backend of Oracle, then I can
> choose some related issues in Trac's list of Oracle issues
> 
>  and
> prepare to work on them during the whole term, right? I've not seen a
> mentor for this project in the GSOC guide, and I think someone here may
> help me.
>

I don't think anyone has specifically stepped forward to mentor an
Oracle-based project, but if you put forward a strong proposal, we will
find someone to mentor you.

As for what to tackle for the project itself - one approach for your
project would be to just tackle a collection of Oracle-related tickets. A
better approach (more likely to be accepted) would be for your to analyse
the tickets that have been reported, and see if you can find a common theme
(or themes) - and then propose a way that we can eliminate those problems
at a higher level.


> (2) Actually I'm familiar with MySQL and SqlServer, but never use Oracle
> before. Will it be a big obstacle in my work if I choose to write the
> backend of Oracle? Or if I begin studying Oracle right now, it won't be a
> problem?
>

A history of Oracle experience would definitely work in your favour, but
*not* having that experience won't necessarily work against you. The fact
that you've got experience with multiple SQL flavours means you should be
aware of some of the interesting ways SQL is interpreted. Highlight that
experience in your application, and that should be enough.

Alternatively, you could try to work with the developers of the SQLServer
backend and see if you could improve support for that backend.


> (3) I'm a new contributor in Django. Before I start working on my project,
> should I start from fix simple bugs or something else?
>

You don't have to, but it would certainly be looked upon favourably. In
particular, if you were to tackle one or two small Oracle bugs, that would
be very helpful to prove that you're going to be able to quickly pick up
the new skills you require for the GSoC term.

Yours,
Russ Magee %-)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-gZuaTGcfbNtJkHB%2BhniZ82A4waymv737xvptvzLcRBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Password validation in Django revisited

2015-03-09 Thread Aymeric Augustin
Hi Erik,

Great work!

Did you consider tying validators to authentication backends? I admit it sounds 
like a bad idea and most likely it is, but since different backends may have 
different security requirements, I'd like to make sure we aren't missing 
something.

Assuming help_text is HTML, you may improve it by building it as follows:

Your password must match the following requirements:

validator 1's requirements
...


This version looks slightly worse when there's only one validator. However I 
expect most sites will use at least two or three validators: minimum length, 
character classes (lower/upper/figures), not a common password (we should ship 
a static blacklist of the top 100 most common passwords, there's tons of 
research on this).

In order to prevent reuse of old passwords, you need to add another method to 
the validator class that is called after the password is successfully changed. 
Otherwise, if the user submits a password change form and the new password goes 
through the validators successfully but the submission fails for some other 
reason (e.g. the current password is wrong), then the user can't re-submit the 
same new password, even though they never used it.

-- 
Aymeric.

> Le 8 mars 2015 à 15:47, Erik Romijn  a écrit :
> 
> Hello all,
> 
> I've taken another stab at 16860[1]: having a password validation/policy in 
> Django. I've made an initial simple PR[2] to show the approach I'd like to 
> use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, influencing 
> the later possibilities, which I'll try to outline below.
> 
> Users choosing awful passwords is a serious security issue. Although password 
> validation can only go so far - especially to the extent that we can 
> implement in Django itself - to me it seems part of our responsibility in 
> helping Django developers to build safer websites.
> 
> First, let me briefly describe my approach: we add a new setting to define 
> zero or more password validator classes. Optionally, a class can be provided 
> with custom arguments to it's constructor. Each validator class has a 
> help_text() method and a validate(password, user) method. The former produces 
> a translatable sentence to be included in the form field's help text. The 
> validate method validates a certain password, optionally taking the context 
> of a user into account and passes its judgement on the password. If a 
> validator considers a password insufficient, it raises a ValidationError.
> 
> This is tied to the validation and form field setup in SetPasswordForm and 
> AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as I 
> feel this validation should primarily take place on the user frontend site 
> with forms. This mirrors the way we typically handle this in Django. Should 
> someone feel different, and want to tie this to set_password() as well, this 
> is possible with a custom user object. Tying this validation into any other 
> place is also trivial: just adding a single line.
> 
> I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised in 
> previous discussions on this issue.
> 
> In the ticket, Shai described a few particular goals for this feature:
> 
> - Informing the user of the various password requirements: this is possible 
> by each validator providing a description, which can be dependent on it's 
> configuration, of it's requirements. Independent sentences from different 
> validators are now concatenated, an approach which will not always yield the 
> prettiest language.
> - Allowing policies to chain together smoothly: multiple validators can be 
> run sequentially, stopping after the first failure.
> - Provide flexibility for complex requirements (some may include their own 
> models): this is entirely possible within the design.
> - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template.
> - Javascript validation assistance or HTML5 support: not implemented 
> currently, but this could be added in a similar way as help texts.
> - Prevent using email, username or other user attributes as (part of) 
> passwords: where possible, the user object is passed to the validator. 
> There's a (not pretty) example of this in the PR.
> - Prevent reuse of old passwords: it is possible in the design for a 
> validator to store all passwords it saw. I have doubts on whether this would 
> be a good approach though.
> 
> So I think this design makes it simple to have sane defaults for new 
> projects, 

Re: Drop the TEMPLATE_DEBUG setting

2015-03-09 Thread Preston Timmons
Hey Curtis,

I was working to remove origin.reload and ended up with a fork that 
combines the debug implementation:

https://github.com/django/django/pull/4254

On a complex template with debug off I'm measuring about a 5% increase in 
template compile time compared to master. Turning debug on adds another 1% 
on top of that. That's a lot better than the current debug implementation.

80-90% of the additional time seems to be in the lexer, not the parser. 
This is due to the finditer loop being used to annotate the start and end 
position of each token in the template source.

Preston

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8c7e0662-71c3-4fde-b4e7-8f334bd38112%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC 2015 project ideas suggestion

2015-03-09 Thread Asif Saifuddin
About the best practice project idea I'm analyzing contrib apps. I found
Admin docs app using class based views and probably it's almost up to date.
for admin and some other apps there are no class based views used. for
revamping django admin as a part of best practice update hoow about
extending django admin with the ideas from 3rd party apps llike djang admin
2? or others. just for querying

Regards

On Fri, Mar 6, 2015 at 2:26 AM, Tim Graham  wrote:

> I have seen that error on my own system Ubuntu 14.04 & Python 3.4.2
> (installed from source), but didn't investigate the cause. I just installed
> Python 3.4.3, however, and don't have the problem there. Now I've
> reinstalled 3.4.2 and the error is resolved there as well.
>
>
> On Thursday, March 5, 2015 at 2:29:36 PM UTC-5, Asif Saifuddin wrote:
>>
>> Hi,
>>
>> running django test suite under python 3.4.3 on my ubuntu 14.10 produce
>> the below output
>>
>> ERROR: test_extract_function (utils_tests.test_archive.TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 42, in test_extract_function
>> extract(self.archive_path, self.tmpdir)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 138, in __init__
>> self._archive = tarfile.open(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line
>> 1553, in open
>> raise ReadError("file could not be opened successfully")
>> tarfile.ReadError: file could not be opened successfully
>>
>> ==
>> ERROR: test_extract_function_no_to_path (utils_tests.test_archive.
>> TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 51, in test_extract_function_no_to_path
>> extract(self.archive_path)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 138, in __init__
>> self._archive = tarfile.open(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line
>> 1553, in open
>> raise ReadError("file could not be opened successfully")
>> tarfile.ReadError: file could not be opened successfully
>>
>> ==
>> ERROR: test_extract_function_with_leadpath (utils_tests.test_archive.
>> TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File "/home/asif/foss/django/tests/utils_tests/test_archive.py", line
>> 46, in test_extract_function_with_leadpath
>> extract(self.archive_lead_path, self.tmpdir)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 49, in extract
>> with Archive(path) as archive:
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 58, in __init__
>> self._archive = self._archive_cls(file)(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/site-
>> packages/Django-1.9.dev20150303124612-py3.4.egg/django/utils/archive.py",
>> line 138, in __init__
>> self._archive = tarfile.open(file)
>>   File "/home/asif/.pyenv/versions/3.4.3/lib/python3.4/tarfile.py", line
>> 1553, in open
>> raise ReadError("file could not be opened successfully")
>> tarfile.ReadError: file could not be opened successfully
>>
>> ==
>> ERROR: test_extract_method (utils_tests.test_archive.TestBzip2Tar)
>> --
>> Traceback (most recent call last):
>>   File 

Re: Testing email settings

2015-03-09 Thread Aymeric Augustin
2015-03-09 17:44 GMT+01:00 Gavin Wahl :

> I expect this command to work with any email backend and to actually do a
> complete, end-to-end test of the configuration.
>
> I agree.

Another example: my SMTP provider will accept emails but put them on hold
until you've validated the sender's address. Only an end-to-end test can
detect this.

-- 
Aymeric.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWwhtE5oMtBhOQAcMA-HtxpSkgzXxSmHXEXDCAED6Uk_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Testing email settings

2015-03-09 Thread Gavin Wahl
> Thus, the test sending email is quite unnecessary, I would like a check
that connects to the SMTP server (if the emails settings are
setup else do nothing) when the application starts.

This wouldn't be useful to me at all. For one, it only is defined for an 
SMTP backend. Also, I wouldn't trust that a successful connection means 
that the configuration is correct. I've seen circumstances, especially if 
sending through a local sendmail, that will result in a successful 
connection but there is still a misconfiguration. 

I expect this command to work with any email backend and to actually do a 
complete, end-to-end test of the configuration.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6645495f-dbd3-42b9-afc4-5c5a204af487%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[ANNOUNCE] Security releases and advisory issued (1.7.6 and 1.8b2)

2015-03-09 Thread Tim Graham
Today the Django team issued multiple releases -- Django 1.7.6 and 1.8b2 -- 
as part of our security process. These releases address a publicly reported 
security issue, and we encourage all users to upgrade as soon as possible.

More details can be found on our blog:

https://www.djangoproject.com/weblog/2015/mar/09/security-releases/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com, and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bacc812a-5289-4cf1-be2b-9e87b5f13244%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-09 Thread Marten Kenbeek
After all the feedback I got here and at the sprint, I think the core of my 
proposal will be the revamping of the current dispatcher and creating a 
public API. I'll keep in mind the other features and in general the 
extendibility of the new dispatcher, and if there is time left I'll start 
implementing some of them.

One interesting note is how content management systems try to work with the 
url dispatcher. Most systems simply use a catch-all pattern. This often 
includes custom machinery to resolve and reverse url patterns for pages, 
blog posts, and other content types or plugins. Django's url dispatcher is 
completely static in that it doesn't provide any public API to change the 
url configuration after it has been loaded. This can be problematic with 
the dynamic nature of CMS's, hence the custom machinery. Bas (bpeschier) 
had to take it to a new level by routing certain content entries to a 
custom view. If you want to avoid a "router" view (which is the url 
dispatcher's job after all), you'd need to dig into the internals of the 
url dispatcher to have any kind of dynamic updating of the configuration.

I'd like to keep this dynamic nature in mind when designing the new API, 
and in time implement a public API for this as well (e.g. a simple 
`register` and `unregister`). This would avoid the need for either a router 
view or unique url prefixes for each content type as well. It should 
certainly allow for granular control, I believe reloading the complete url 
dispatcher can take quite some time (I should probably test that). 

I'm still in doubt on whether I should implement a refactor of url 
namespaces and middleware. Url namespacing is overly complex and I'm not 
too sure what the exact goal of the mechanism is. It obviously needs to 
differentiate multiple instances of the same url configuration, and it is 
also used to differentiate url configurations as well as to provide a 
default instance for an url configuration. I'm not too sure what is 
absolutely needed and what just makes it more complicated than necessary. 
However, as namespaces are such an integral part of the dispatcher, it is 
worth looking into and it might be necessary to keep in mind with the new 
API. 

As for middleware, I'm inclined to only support per-include decorators. 
Users can always use `decorator_from_middleware` to define middleware for a 
subset of views. While middleware certainly needs a revamp, I'm not too 
familiar with its current issues, and I feel this is slightly out of this 
project's scope. 

On Friday, March 6, 2015 at 5:21:01 PM UTC+1, Tom Christie wrote:
>
> > E.g., flask uses a simple `` to match an integer and capture it 
> in the `id` parameter. Support to check for conflicts would be a lot 
> simpler with those patterns. It would definitely be a best-effort feature.
>
> From my point of view, this by itself would make for a really 
> nicely-scoped GSoC project.
> Being able to demonstrate an API that allowed the user to switch to a URL 
> resolver that used that simpler style would be a really, really nice 
> feature,
> and also feels like it might actually be a manageable amount of work.
> This wouldn't *necessarily* need to allow decorator style routing, instead 
> of the current URLConf style, but that might also be a nice addition. 
> Personally though I would consider tackling that as an incremental 
> improvement.
>
> Things I'd be wary of:
>
> * Anything around "continue resolving" exceptions or object inspection 
> during routing, both of which sound like an anti-pattern to me.
> * Method based routing. Feel less strongly about this, but still not 
> convinced that it's a good style.
> * Generic views / model routes / automatic routing. Too broadly defined, 
> and with no clear best answer.
>
> Anyways, interesting stuff Marten, look forward to hearing more.
>
>   Tom
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0bf15653-717c-4e24-8406-14fa71bf5bf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


GSOC 2015: Improving the less popular database backends

2015-03-09 Thread Yichun Duan
Hi,

I'm Yichun and I'm interested in the Project ' Improving the less popular 
database backends' in GSOC 2015. I major in computer science in Peking 
University. I've worked with C++, Java, Python and I've written several 
webapps using Django. 

I have some questions related to this project and your answers will be of 
big help.

(1) I'd like to make sure that I've understood this project in a right way. 
For example, if I choose to improve the backend of Oracle, then I can 
choose some related issues in Trac's list of Oracle issues 

 and 
prepare to work on them during the whole term, right? I've not seen a 
mentor for this project in the GSOC guide, and I think someone here may 
help me.
(2) Actually I'm familiar with MySQL and SqlServer, but never use Oracle 
before. Will it be a big obstacle in my work if I choose to write the 
backend of Oracle? Or if I begin studying Oracle right now, it won't be a 
problem?
(3) I'm a new contributor in Django. Before I start working on my project, 
should I start from fix simple bugs or something else?

Thanks,
Yichun

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d28c2c91-2a44-4d38-9815-c08e06d1bb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Composite fields

2015-03-09 Thread Anssi Kääriäinen
On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson  wrote:
>> It doesn't result in good table design and adds restrictions/complication
>> to the ORM/migrations.
>
> Well, honestly, making all subfields always nullable (whether it is or not)
> in order to support the composite field being potentially nullable doesn't
> really result in good table design either.
>
>> Enforcing that both x and y have a value should be handled with a
>> constraint and/or validators.
>
> There is _no_ problem that is better handled with validators than an
> equivalent database constraint unless you assume that the framework is the
> only client your database will ever have.

You'll likely need both. The database constraint is there to catch all
errors, whether generated by the framework or some other client. The
validator will supply nice user-facing error messages. This is how
unique constraints work for example: there is a model validator that
says "this value already exists in the database", but we also have
database level constraint to make sure there is no way to store
invalid values.

>> -1 on silently changing the field definition. At best this would result in
>> an unnecessary migration when the error is discovered. Django should error
>> out with a message that the composite field definition is invalid.
>
> Changing the subfield definitions in the composite field constructor has to
> be supported, there's no way of passing parameters to subfields if you
> don't. What mistake is there to be found? Either you want the composite
> field to be nullable or you don't. You're being explicit about it by passing
> `null=True` into the field definition and it's a standard field parameter.

If the user supplies the fields, then we don't want to change them
silently. We could have checks framework error for incompatible
settings however. If the field auto-creates the subfields, then it can
alter them in any way it wishes.

Making the composite field null only when all of its subfields are
null seems the right behavior to me. Otherwise you'd have strange
cases where .filter(money__amount=10) is true, but
.filter(money__isnull=True) is also true for the same row.

 - 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALMtK1GCSfemy%2BN0HLPMbsovwgcSy%2BwEw6QF-%2BoZ-tfBCTSkUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Composite fields

2015-03-09 Thread Thomas Stephenson
> It doesn't result in good table design and adds restrictions/complication
to the ORM/migrations.

Well, honestly, making all subfields always nullable (whether it is or not)
in order to support the composite field being potentially nullable doesn't
really result in good table design either.

> Enforcing that both x and y have a value should be handled with a
constraint and/or validators.

There is _no_ problem that is better handled with validators than an
equivalent database constraint unless you assume that the framework is the
only client your database will ever have.

Also, I'm not sure where the "constraint" is coming from, since we've
removed the possibility of providing a NOT NULL constraint on the column.

> -1 on silently changing the field definition. At best this would result
in an unnecessary migration when the error is discovered. Django should
error out with a message that the composite field definition is invalid.

Changing the subfield definitions in the composite field constructor has to
be supported, there's no way of passing parameters to subfields if you
don't. What mistake is there to be found? Either you want the composite
field to be nullable or you don't. You're being explicit about it by
passing `null=True` into the field definition and it's a standard field
parameter.



But I'm happy for that to be the final word on the matter and I'll remove
it from the spec. I haven't found a single person who thinks that
supporting it is a good idea, so that's probably a good indication that it
isn't.

On 9 March 2015 at 03:52, Michael Manfre  wrote:

> -1 on silently changing the field definition. At best this would result in
> an unnecessary migration when the error is discovered. Django should error
> out with a message that the composite field definition is invalid.
>
> Regards,
> Michael Manfre
>
> On Sun, Mar 8, 2015 at 12:29 PM, Thomas Stephenson 
> wrote:
>
>> ps. There's a third option which I just thought of:
>>
>> class Point(...):
>>x = models.IntegerField()
>>y = models.IntegerField()
>>z = models.IntegerField(null=True)
>>
>>def __init__(self, null=False, **kwargs):
>>if null:
>>  x.null = y.null = True
>>   super(Point, self).__init__(**kwargs)
>>
>>def deconstruct(self):
>>   # etc.
>>
>> The framework could handle this and mandate "If a composite field has
>> `null=True`, then all subfields are forced into the state `null=True`
>> etc.", applying the `__init__` and `deconstruct` stuff itself.
>>
>> Yep -- I like this solution better.
>>
>> Thomas
>>
>>
>> On 9 March 2015 at 03:12, Thomas Stephenson  wrote:
>>
>>> @Aymeric
>>>
>>> Here's why I think the `isnull` column is necessary.
>>>
>>> Say you've got a custom field implementation:
>>>
>>> class Point(models.CompositeField):
>>>  x = models.IntegerField()
>>>  y = models.IntegerField()
>>>  # etc.
>>>
>>> and you use this to define a coordinate system to locate objects in your
>>> models. You justify that whenever you provide a point, you'll want both an
>>> x and y coordinate, so you make both of the subfields non-null.
>>>
>>> But then you come across a model which may or may not have a location.
>>> You'd like to say
>>>
>>> class MaybeLocatable(models.Model):
>>>point = Point(null=True)
>>>
>>> but you can't, because both of your subfields are non-nullable, so you
>>> define a nonsensical condition to apply to your Point
>>> "If I don't have an x-coordinate, then the point value should be
>>> considered null"
>>> so you update the Point field appropriately (and apply all the necessary
>>> migrations).
>>>
>>> You then want to query for all `MaybeLocatable` objects that are
>>> considered null. You can query for point__isnull=True (which is supposed to
>>> be supported). How does one define the lookup transformation for that?
>>>
>>> If there was an implicit 'isnull' column added, then the lookup
>>> transformation for both `point__isnull=True` and `point=None` become a
>>> lookup for the database column `point__isnull = True`. If you don't add
>>> that extra column, how does the framework what transform to make? It could
>>> query for both `point__x__isnull` and `point__y__isnull`, but that wouldn't
>>> match the semantics for the column.
>>>
>>> And you also can't say "well, look at the field definition and if a
>>> column is nullable, then use it as a marker, because what if you instead
>>> had:
>>>
>>> class Point(models.CompositeField):
>>>x = models.IntegerField(null=True)
>>>y = models.IntegerField()
>>>z = models.IntegerField(null=True)
>>>
>>> as your original class? `x` could still be used as the "marker" column,
>>> but any transformation you'd make with the above rule. So the framework
>>> can't actually define a workable `isnull` query (or an 'exact' query when
>>> the python value is `None`). The whole issue of the "marker" column is
>>> fraught anyway, because it breaks all