Re: #20824 - Email-based auth contrib module; some help required

[schinckel]

On Friday, February 28, 2014 12:55:31 PM UTC+10:30, waylan wrote:
>
> On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote:
>>
>> normalize_email will indeed allow both us...@example.com and 
>> us...@example.com to be different entities. From the user perspective, 
>> this is an error. Most probably the user enters some day their email in all 
>> upper case because he pressed the CapsLock key, or copy pasted a transcript 
>> of his email, etc., the user could not be able to figure out the difference 
>> and simply could not log in.
>>
>
>
[snip]
 

>  
> The point is that the user will inadvertently type 
> u...@example.com on 
> their mobile device after registering with us...@example.com  on 
> their desktop/laptop. And they won't understand why they can't log in if it 
> is case sensitive. Given that both addresses will deliver email to the same 
> email account, it seems to me that both should be valid for the same 
> account as an email based username on a sign-in form.
>

But there's the rub. Whilst for _most_ email servers, this will indeed send 
mail to the same account, there's nowhere that says this _must_ happen.

Relevant: 
http://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive

Matt. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/ab6fb338-252e-42f5-a83f-fd414d49432c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #20824 - Email-based auth contrib module; some help required

[waylan]

On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote:
>
> normalize_email will indeed allow both us...@example.com and 
> us...@example.com  to be different entities. From the user 
> perspective, this is an error. Most probably the user enters some day their 
> email in all upper case because he pressed the CapsLock key, or copy pasted 
> a transcript of his email, etc., the user could not be able to figure out 
> the difference and simply could not log in.
>

How about a more common real world situation -- on mobile devises? They 
will often "helpfully" assume the first letter of the first word in a field 
should be uppercase and do so for you. You have to be paying attention and 
specifically tap the shift key before typing to turn it off, then type your 
email address.
 
This is an annoyance of mine because native UIs will often recognize that 
you are typing in an email field and not do this (even giving you a custom 
keyboard with the @ symbol), but web pages will not. Perhaps on some 
devices  does the right thing -- but in my experience it 
isn't consistent (based on general observations only).
 
The point is that the user will inadvertently type u...@example.com on 
their mobile device after registering with u...@example.com on their 
desktop/laptop. And they won't understand why they can't log in if it is 
case sensitive. Given that both addresses will deliver email to the same 
email account, it seems to me that both should be valid for the same 
account as an email based username on a sign-in form.
 
 Waylan Limberg
 

> Is preferable to think, in this case, in protecting the user from their 
> own mistake (from our perspective as programmers), and do as Atul 
> Bhouraskar says: transform the email data in a consistent way before 
> insert/update/search to the DB.
>
> On Wednesday, February 26, 2014 8:31:40 PM UTC-4:30, Atul Bhouraskar wrote:
>>
>> Won't normalize_email will allow two distinct users us...@example.comand 
>> us...@example.com to be created? Case insensitive searches will return 
>> multiple users for a 'get'.
>>
>> Perhaps the closest we can get is to ensure that any user created using 
>> Django functions is saved with a consistent case transformation and then 
>> perform an *exact* search after applying the same transformation to the 
>> input?
>>
>> One idea could be to add a 'transform_email' or similar hook that by 
>> default calls normalize_email and ensure that it is applied both to data 
>> that is about to be saved and to search terms. Projects that wish to change 
>> the behaviour can simply override transform_email to perform for example 
>> lowercase conversion if so desired.
>>
>> Atul
>>
>>
>> On 27 February 2014 11:43, Russell Keith-Magee wrote:
>>
>>>
>>> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney <
>>> cur...@acommoncreative.com> wrote:
>>>
 Doesn't the UserManager already have a "normalize_email" method which 
 lower-cases the domain and leaves the mailbox name alone?

 IMHO It's "proper" to leave it this way by default, and probably 
 mention in the docs it's used so if you want to change it, that's the hook.

>>>
>>>  It does - assuming you use User.objects.create_user() to create all 
>>> your users. However, the UserCreationForm doesn't use this (and hasn't ever 
>>> used this); it also doesn't account for fixtures, or any other path into 
>>> the database that might exist. 
>>>
>>> So - while normalising case is probably a good idea, and should probably 
>>> be added to the Create/Update User form, the searches will still need to be 
>>> case insensitive.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/30f6abcc-d1fc-417d-aa44-aa5b519bdc54%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The restricted usage of auth.User model when using custom AUTH_USER_MODEL

[Burak Emre Kabakcı]

OK, I give up. Actually I asked another question related to this topic 
before developing the application but the answers were similar to yours. 
(https://groups.google.com/forum/#!topic/django-developers/EnMn9_hU5g0)

I had to use monkey-patching to allow dynamic AUTH_USER_MODEL but it wasn't 
a good idea so later I decided to separate the admin part and use 
different AUTH_USER_MODEL settings for each app. However, even separating 
the applications does not solve the problem because the core Django code 
does not assume that I can have different AUTH_USER_MODEL settings even if 
I use them in different server instances.

Actually the customer model and staff model don't share and fields except 
password, last_login and created_at but since I use OneToOneField in order 
to map extra fields it's ok to store all common type of data in one table.

I don't really like the idea of providing a regular customer user for 
staffs because when a staff logins into admin site, he/she also logins into 
the frontend site which makes harder to view the site as anonymous. Also it 
becomes much more difficult if I develop a feature "Login as x customer".

The only useful solution that I found is to move the admin page to another 
subdomain (with reverse proxies like nginx) in order to prevent them to 
share cookies. And I also created 2 proxy models called customer and staff 
and modified their managers so that they can act like separate models.

On Friday, February 14, 2014 12:45:16 AM UTC+2, Russell Keith-Magee wrote:
>
>
> On Fri, Feb 14, 2014 at 1:06 AM, Burak Emre Kabakcı 
>  > wrote:
>
>> I have two applications: One of them uses default auth.User model and the 
>> other one uses another AbstractUser class configured as AUTH_USER_MODEL. 
>> These two apps uses same codebase except their settings.py file. One of the 
>> models has a ForeignKey field in relation with auth.User model (I use 
>> auth.User as the staff model) and due to restriction of auth.User I'm not 
>> able to run the other application since I use custom AUTH_USER_MODEL. 
>> Django throws this error:
>>
>> django.core.management.base.CommandError: One or more models did not 
>> validate:
>> model: 'staff' defines a relation with the model 'auth.User', which has 
>> been swapped out. Update the relation to point at settings.AUTH_USER_MODEL.
>>
>> I couldn't get why the usage of User model is restricted in this case. 
>> The only workaround I can found is monkey-patching the swappable field in 
>> User model's Meta field.
>>
>
> It's not clear if this question is better suited for django-users, or if 
> you're asking with a view to contributing a patch to Django. For future 
> reference, if this is a "How can I do this" question, it's better suited to 
> Django-users. 
>
> However, if you're considering options for "fixing" this: The reason the 
> validation code does this is to ensure that the authentication code will 
> work. 
>
> At a conceptual data storage level, what you describe would be fine - 
> admin users are normal auth.Users, regular users are myauth.MyUser. 
> However, a user model isn't just used for data storage -- it's used for 
> authentication and login, and Django's authentication framework can only 
> handle one authentication model. AUTH_USER_MODEL defines which model that 
> will be.
>
> So - if the model validation code allowed for the situation you describe, 
> you would have an admin user model, but no admin user would ever be able to 
> log in. 
>
> This isn't *necessarily* insurmountable; the auth backends tool would, in 
> principle, allow authentication against different data sources; we'd just 
> need to have a "I don't care what AUTH_USER_MODEL says, use auth.User" 
> ModelBackend in addition to the actual ModelBackend that Django provides 
> out of the box. You'd also need to make some changes to ensure that even 
> though AUTH_USER_MODEL has been swapped out, you still want it to be 
> synchronised - as currently set up, defining a value for AUTH_USER_MODEL 
> other than auth.User causes auth.User to not be created on disk. 
>
> However, I'm not convinced that this would be a worthwhile set of changes. 
> If you go back to your original use case - why do you need two user models? 
> Is there any reason that this can't be done the way Django does this right 
> now - with a single user model that has a concept of "admin"? If 'system' 
> users have additional data requirements, or you want to maintain a 
> foreign-key level protection to ensure that admin users can't "own" data, 
> then add a profile model to capture the idea of a 'system' user, and keep a 
> foreign key between that user and the base User model. This approach 
> separates the two concepts of authentication and authorisation -- the User 
> model is used to identify that person X is who they say they are, the 
> profile model is used to determine that person X is allowed to see 
> particular content.
>
> This approach has the added 

Re: #20824 - Email-based auth contrib module; some help required

[Camilo Torres]

normalize_email will indeed allow both u...@example.com and 
u...@example.com to be different entities. From the user perspective, this 
is an error. Most probably the user enters some day their email in all 
upper case because he pressed the CapsLock key, or copy pasted a transcript 
of his email, etc., the user could not be able to figure out the difference 
and simply could not log in.

Is preferable to think, in this case, in protecting the user from their own 
mistake (from our perspective as programmers), and do as Atul Bhouraskar 
says: transform the email data in a consistent way before 
insert/update/search to the DB.

On Wednesday, February 26, 2014 8:31:40 PM UTC-4:30, Atul Bhouraskar wrote:
>
> Won't normalize_email will allow two distinct users 
> us...@example.comand 
> us...@example.com  to be created? Case insensitive searches 
> will return multiple users for a 'get'.
>
> Perhaps the closest we can get is to ensure that any user created using 
> Django functions is saved with a consistent case transformation and then 
> perform an *exact* search after applying the same transformation to the 
> input?
>
> One idea could be to add a 'transform_email' or similar hook that by 
> default calls normalize_email and ensure that it is applied both to data 
> that is about to be saved and to search terms. Projects that wish to change 
> the behaviour can simply override transform_email to perform for example 
> lowercase conversion if so desired.
>
> Atul
>
>
> On 27 February 2014 11:43, Russell Keith-Magee 
>  > wrote:
>
>>
>> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney <
>> cur...@acommoncreative.com > wrote:
>>
>>> Doesn't the UserManager already have a "normalize_email" method which 
>>> lower-cases the domain and leaves the mailbox name alone?
>>>
>>> IMHO It's "proper" to leave it this way by default, and probably mention 
>>> in the docs it's used so if you want to change it, that's the hook.
>>>
>>
>>  It does - assuming you use User.objects.create_user() to create all your 
>> users. However, the UserCreationForm doesn't use this (and hasn't ever used 
>> this); it also doesn't account for fixtures, or any other path into the 
>> database that might exist. 
>>
>> So - while normalising case is probably a good idea, and should probably 
>> be added to the Create/Update User form, the searches will still need to be 
>> case insensitive.
>>
>> Yours,
>> Russ Magee %-)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/123a986f-8133-4af1-99aa-34f6227d467b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Russell Keith-Magee]

On Fri, Feb 28, 2014 at 4:17 AM, Gwildor Sok  wrote:

> Personally I'm a big fan of Py.test, simply because it's so simple and
> Pythonic to use. Simple functions with simple assert statements. That's
> all. For me this significantly lowers the threshold to write tests and
> requires less effort, which in the end results in way more tests written in
> Py.test than the testsuite Django is currently using.
>

This is an argument that I've never understood. Why is typing:

class MyTestCase(TestCase):

such a burden? Because once you've typed that, everything else in the class
is "just a method". However, you also get the added benefit of test
grouping, and if you've got common setup/teardown requirements, the class
provides a place to put them.

I know py.test has a lot of fans, but I'm seriously unconvinced by the
"it's so easy to write tests" argument.

For this proposal to be acceptable to core, it's going to need to start
with a *comprehensive* analysis of why py.test is a better approach to
take. Don't just assume everyone is on board.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq848t5Zk55FEd6_Fd4hMy4JqFV7yZg7wTn7sQbZpuM%2BHHig%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

As suggested by Tim Graham, I am going to post my analysis on respective 
tickets.
But there are some issues where I need help in analysing, I have mentioned 
those in my above posts. Also there may be issues for which ticket have not 
been opened, they are only mentioned in the wiki page.
Hence, it is my humble request to please go through the issues here as well 
once for the above mentioned reasons.

Regards,
Anubhav Joshi
IIT Patna

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/9a60e1fa-574b-4ad1-8f06-0b6dec500480%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

As suggested by Tim Graham, I am going to put my analysis on respective 
tickets.
Also it is possible that some issues are directly mentioned on wiki 
page(there is no ticket for them), so its a humble request to please go 
through it once here.

Regards,
Anubhav Joshi
IIT Patna

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/fb56799c-8dcb-4837-9f6b-53fb9a312cd0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[Tim Graham]

I believe if your tickets are enough work to fill 12 weeks, someone is not 
going to come along and complete a majority of them in the meantime. You 
can also add something like "I hope to work on this ticket for GSoC 2014."

On Thursday, February 27, 2014 3:57:45 PM UTC-5, anubhav joshi wrote:
>
>
>
> On Friday, February 28, 2014 2:03:10 AM UTC+5:30, Tim Graham wrote:
>>
>> I think it'll be better to put your analysis of each ticket on the ticket 
>> itself. Then when you're finished with that, put together a more high level 
>> overview of the analysis you've done. I think it will be easier to give 
>> feedback if you structure your thoughts in this way. Thanks!
>>
>>
>> If I put my analysis on all the tickets that I have studied and analysed, 
> and then if someone on studying that analysis, fixes the issue then what 
> will I put in my proposal? I mean I have to ensure that I have sufficient 
> work for GSoC. How do I that ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/5a5dfc2c-f55e-4698-a623-3249037e643b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

On Friday, February 28, 2014 2:03:10 AM UTC+5:30, Tim Graham wrote:
>
> I think it'll be better to put your analysis of each ticket on the ticket 
> itself. Then when you're finished with that, put together a more high level 
> overview of the analysis you've done. I think it will be easier to give 
> feedback if you structure your thoughts in this way. Thanks!
>
>
> If I put my analysis on all the tickets that I have studied and analysed, 
and then if someone on studying that analysis, fixes the issue then what 
will I put in my proposal? I mean I have to ensure that I have sufficient 
work for GSoC. How do I that ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/cb499d9a-7646-44bd-9994-c723f7758110%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[Tim Graham]

I think it'll be better to put your analysis of each ticket on the ticket 
itself. Then when you're finished with that, put together a more high level 
overview of the analysis you've done. I think it will be easier to give 
feedback if you structure your thoughts in this way. Thanks!

On Thursday, February 27, 2014 3:15:42 PM UTC-5, anubhav joshi wrote:
>
> Here is another issue that I have analysed.
>
> *When the autogenerated field name is too long, there is no proper 
> displaying of errors, many a time silent failures for some database.*
> Written a fix, although some thinking is required in writing the tests.
>
> @classmethod
> def _check_long_column_name(cls):
> errors = []
> allowed_len = None
> db_alias = None
>
> for db in settings.DATABASES.keys():
> # skip databases where the model won't be created
> if not router.allow_migrate(db, cls):
> continue
> connection = connections[db]
> allowed_len = connection.ops.max_name_length()
> db_alias = db
>
> if allowed_len is not None:
> for f in cls._meta.local_fields:
> _, column_name = f.get_attname_column()
> """
> Check if auto-generated name for the field is too long
> for the database.
> """
> if f.db_column is None:
> if len(column_name) > allowed_len:
> errors.append(
> checks.Error(
> 'Autogenerated column name too long for field 
> "%s".'
> 'Maximum length is "%s" for "%s".' % 
> (column_name, allowed_len, db_alias),
> hint='Set the column name manually using 
> db_column',
> obj=cls,
> )
> )
>
> return errors
>
> Also it is seen, that *model name truncation is not done properly.*
> self.db_table = truncate_name(self.db_table, 
> connection.ops.max_name_length()) is done.
>
> But, something like the following would be more correct:
>
> db = router.db_for_read(self.model)
> self.db_table = truncate_name(self.db_table, 
> connections[db].ops.max_name_length())
>
> We could also use router.allow_migrate as above.
>
> Also when *db_table name truncation is done, we get a weird message*:
>
> #models.py
> class 
> (models.Model):
> name = models.CharField(max_length=40)
>
> python manage.py syncdb
>
> Creating table 
> probs_aa36a3
> Warning: Data truncated for column 'name' at row 13
>
> Instead of reporting about the truncated name of the model table, it seems 
> to tell about the first field of that table.
> This is something done by the backend I believe.*(Correct me if I am 
> wrong.)*
> Assuming if above is correct, then what we can do is create a warning 
> using warning.warn(...) about the correct issue.
> Then we can remove the false warning arising from the db.
>
> A mention of similar problem at #18959 is there, but as far as I have 
> understood it worksforme or else if someone can help me reproduce the 
> problem/error if I am wrong, then it would be very helpful.
>
> Regards,
> Anubhav Joshi
> IIT Patna
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/8a16ad00-5586-4665-9063-be5c1d49594f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Gwildor Sok]

Personally I'm a big fan of Py.test, simply because it's so simple and 
Pythonic to use. Simple functions with simple assert statements. That's 
all. For me this significantly lowers the threshold to write tests and 
requires less effort, which in the end results in way more tests written in 
Py.test than the testsuite Django is currently using.

This is a talk I watched when I was looking for alternative test suites and 
got me hooked: http://www.youtube.com/watch?v=DTNejE9EraI

On Thursday, February 27, 2014 9:10:58 PM UTC+1, Andrew Pashkin wrote:
>
>
>>>1. Distributed testing (speed up, especially on multi-core 
>>>machines), Line Coverage, etc using plugins
>>>
>>> How would this work? We still have shared resources like the database 
>> where you can't just run 10 Test against in parallel.
>>
>
> There is django plugin for 
> py.testexists, it is able to create 
> separate DBs for each process.
>
> On Thursday, February 27, 2014 11:59:56 PM UTC+4, Florian Apolloner wrote:
>>
>> Hi Akshay,
>>
>> On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote:
>>>
>>> *Why Py.Test?* (http://pytest.org)
>>>
>>>1. Widely Used
>>>
>>> So is nose and unittest, you'll need to add a bit more info to such 
>> statements. 
>>
>>>
>>>1. Better reporting
>>>
>>> Better how exactly? 
>>
>>>
>>>1. Distributed testing (speed up, especially on multi-core 
>>>machines), Line Coverage, etc using plugins
>>>
>>> How would this work? We still have shared resources like the database 
>> where you can't just run 10 Test against in parallel.
>>
>> Cheers,
>> Florian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/63ae1993-33c9-457c-b995-ee3fe079e50f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

Here is another issue that I have analysed.

*When the autogenerated field name is too long, there is no proper 
displaying of errors, many a time silent failures for some database.*
Written a fix, although some thinking is required in writing the tests.

@classmethod
def _check_long_column_name(cls):
errors = []
allowed_len = None
db_alias = None

for db in settings.DATABASES.keys():
# skip databases where the model won't be created
if not router.allow_migrate(db, cls):
continue
connection = connections[db]
allowed_len = connection.ops.max_name_length()
db_alias = db

if allowed_len is not None:
for f in cls._meta.local_fields:
_, column_name = f.get_attname_column()
"""
Check if auto-generated name for the field is too long
for the database.
"""
if f.db_column is None:
if len(column_name) > allowed_len:
errors.append(
checks.Error(
'Autogenerated column name too long for field 
"%s".'
'Maximum length is "%s" for "%s".' % 
(column_name, allowed_len, db_alias),
hint='Set the column name manually using 
db_column',
obj=cls,
)
)

return errors

Also it is seen, that *model name truncation is not done properly.*
self.db_table = truncate_name(self.db_table, 
connection.ops.max_name_length()) is done.

But, something like the following would be more correct:

db = router.db_for_read(self.model)
self.db_table = truncate_name(self.db_table, 
connections[db].ops.max_name_length())

We could also use router.allow_migrate as above.

Also when *db_table name truncation is done, we get a weird message*:

#models.py
class 
(models.Model):
name = models.CharField(max_length=40)

python manage.py syncdb

Creating table 
probs_aa36a3
Warning: Data truncated for column 'name' at row 13

Instead of reporting about the truncated name of the model table, it seems 
to tell about the first field of that table.
This is something done by the backend I believe.*(Correct me if I am 
wrong.)*
Assuming if above is correct, then what we can do is create a warning using 
warning.warn(...) about the correct issue.
Then we can remove the false warning arising from the db.

A mention of similar problem at #18959 is there, but as far as I have 
understood it worksforme or else if someone can help me reproduce the 
problem/error if I am wrong, then it would be very helpful.

Regards,
Anubhav Joshi
IIT Patna


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/588db101-7dd8-49dd-9f55-8dfdd0e98873%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Andrew Pashkin]

>
>
>>1. Distributed testing (speed up, especially on multi-core machines), 
>>Line Coverage, etc using plugins
>>
>> How would this work? We still have shared resources like the database 
> where you can't just run 10 Test against in parallel.
>

There is django plugin for py.test 
exists, it is able to create separate 
DBs for each process.

On Thursday, February 27, 2014 11:59:56 PM UTC+4, Florian Apolloner wrote:
>
> Hi Akshay,
>
> On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote:
>>
>> *Why Py.Test?* (http://pytest.org)
>>
>>1. Widely Used
>>
>> So is nose and unittest, you'll need to add a bit more info to such 
> statements. 
>
>>
>>1. Better reporting
>>
>> Better how exactly? 
>
>>
>>1. Distributed testing (speed up, especially on multi-core machines), 
>>Line Coverage, etc using plugins
>>
>> How would this work? We still have shared resources like the database 
> where you can't just run 10 Test against in parallel.
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/17553c1f-ec24-401f-8b62-91d39f1fbe54%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Florian Apolloner]

Hi Akshay,

On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote:
>
> *Why Py.Test?* (http://pytest.org)
>
>1. Widely Used
>
> So is nose and unittest, you'll need to add a bit more info to such 
statements. 

>
>1. Better reporting
>
> Better how exactly? 

>
>1. Distributed testing (speed up, especially on multi-core machines), 
>Line Coverage, etc using plugins
>
> How would this work? We still have shared resources like the database 
where you can't just run 10 Test against in parallel.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/f30c83e7-883e-4644-b8bc-3de46e22a6d1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[GSOC] Shifting to Py.Test and Improving the Test Suite

[Akshay Jaggi]

Sorry for starting a new thread but I thought a proposal should begin with 
a new thread. 
(Please refer to the previous thread 
@ https://groups.google.com/forum/#!topic/django-developers/GO65Qndw4Hg )

I'm writing in points, for easier readability. This is a very brief summary 
I actually wrote down for myself.

*Need for Improvement/ Current Problems*

   1. Running of Test Cases is slow. 
   2. Selection of what tests we want to run, and what all we don’t want to 
   run is difficult
   3. We have better options available


*Why Py.Test?* (http://pytest.org)

   1. Widely Used
   2. Better reporting
   3. Distributed testing (speed up, especially on multi-core machines), 
   Line Coverage, etc using plugins
   4. Third party plugins


*Why Categorisation?*

   1. Easy to manage tests
   2. User can specify own types suitable to him. For instance -> Phase-I, 
   Phase-II, Regression, unit, module-1, system, integration,etc
   3. User can run tests in chunks (say of 2,3 test-classes belonging to a 
   particular category) ->Faster run, as we run tests only pertaining to 
   currently-being-modified module.
   4. Ease in specifying what tests to run


*How will I go about it?*

Currently SimpleTestCase is a subclass of unittest.TestCase. Two ways exist 
->

   1. Make our own class, which gives all functionalities of 
   unittest.TestCase in terms of Pytest constructs
   2. Modify SimpleTestCase, TransactionTestCase, TestCase to use Pytest 
   Constructs

(*Pytest anyway supports unittest TestCases, Why is this required?*Difference 
in the way both define their constructs, causes incompatibility 
in certain cases. This results in false-positives. About 200 previously 
passing Tests are reported as failed when using pytest-django)

Redefine discovery and runner accordingly.

We don’t want broken tests. Check *all* Test Cases for false positives, 
especially those which do not have failure test cases defined.

Now add ability to categorise in SimpleTestCase -> just a list of tags, 
specified for each test-class. (or test function?)

Add ability in discovery to run only the tests, which have the tags as 
required. 
Hence discovery can now be using paths, test-labels, pattern or tags. It 
can also be intersection or union of any combination of these. 

Test cases to be run can be defined as defaults in a config file or through 
the command line.


I'll be glad to hear your views. 

Thanks.

Akshay Jaggi


P.S. - Another way to categorise can be using a configuration file. We can 
specify groups, and add all test-labels that belong to that group in this 
file. This way, classification won't be declarative in code, but in a 
separate file.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/bb9c0294-8d2a-432b-b651-ed6e2795092f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

On Wednesday, February 26, 2014 7:43:49 PM UTC-8, Russell Keith-Magee wrote:
>
> Hi Anubhav,
>
> Please keep in mind that this is a global mailing list, and if you want 
> considered feedback, it's going to take time. Posting two "Please give me 
> feedback" pings in 6 hours isn't especially helpful. There will be people 
> who have been asleep for that entire period.
>
> Yours,
> Russ Magee %-)
>
>
Apologies for being over eager.

Regards,
Anubhav Joshi
IIT Patna 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/5918083d-b428-4f4b-babc-afd0e831549c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.