Re: Feature proposal: Allow shadowing of abstract fields

[Marten Kenbeek]

Hi Russ,

I can see your point on accidentally overriding fields, though I'm not sure 
I agree. In any other case, such as normal attributes and methods, there is 
no safety net for overriding attributes either. Any model that would be 
affected by this change would also raise an error on import without the 
patch, so existing functional code won't be affected. On the other hand, a 
new parameter for the field wouldn't be that much of a hassle to implement 
or work with. I'd be interested to hear what others think about this.

There are more than a few questions 

 
on stack overflow that expect this behaviour, even if the docs specifically 
mention that it won't work. If users intuitively try to override fields in 
this manner, I think it would be reasonable to allow this without any 
explicit arguments.

We can always restrict what you can override, at least as the default 
behaviour, e.g. so that you can only use subclasses of the original field. 
That would make code that depends on the abstract field less prone to bugs, 
though subtle bugs can still happen if you e.g. override the max length of 
a field. 

This was indeed just a proof-of-concept. That remark was meant more like 
"it doesn't appear to break everything". 

Marten

Op vrijdag 6 februari 2015 23:48:55 UTC+1 schreef Marten Kenbeek:
>
> Hey,
>
> While fiddling with django I noticed it would be trivial to add support 
> for shadowing fields from abstract base models. As abstract fields don't 
> exist in the database, you simply have to remove the check that reports 
> name clashes for abstract models, and no longer override the field. 
>
> This would allow you to both override fields from third-party abstract 
> models (e.g. change the username length of AbstractUser), and to override 
> fields of common abstract models on a per-model basis. Previously you'd 
> have to copy the original abstract model just to change a single field, or 
> alter the field after the model definition. The first approach violates the 
> DRY principle, the second approach can introduce subtle bugs if the field 
> is somehow used before you changed it (rare, but it can happen). 
>
> This patch 
> 
>  adds 
> the feature. It seems to work correctly when using the models and 
> creating/applying migrations, and passes the complete test suite. 
>
> What do you guys think about this feature?
>

-- 
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/072149e1-c794-446d-957b-f5fc5df87096%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

User.username max_length 254

[Collin Anderson]

Hi All,

I was reminded by:
Allow shadowing of abstract fields 
https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
small tweaks).

Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
User.username max_length to 254?

Personally, that's the only thing I've ever needed to change about my User 
class. I just need it long enough to hold email addresses. I've seen many 
other people wanting the same thing.

In 1.8 we migrated the length of EmailField from 75 to 254, so it should be 
almost™ as easy to change the username field.

If needed, we could keep the 30-character limit on UserCreationForm and 
UserChangeForm for backwards compatibility. The limit in the database is 
the real killer :) Though, consistency is also nice.

Thanks,
Collin

-- 
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/3cbf2307-dc8c-475b-909b-360fb2597a50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Allow shadowing of abstract fields

[Russell Keith-Magee]

Hi Marten,

I can understand the motivation, and the approach you've taken makes sense.
It definitely strikes me as a much better alternative to tickets like
#24288 than a setting.

https://code.djangoproject.com/ticket/24288

The DRY issue isn't a huge problem for me - it's certainly ungainly to not
have a clean way to override an abstract field, but I'm not sure I see a
particularly Pythonic alternative.

My only real concern is the potential for accidentally overriding
something. This isn't especially likely on a field like "username" on a
User model - but a more esoteric field, like "is_staff" would be easy to
add twice, because it might not be obvious that the abstract model is
providing the field that you're overriding. Some sort of safety catch
(e.g., requiring override_abstract=True in an overriding definition) might
be a way around this.

So - I think it's worth kicking around; I'm definitely interested in
hearing if others have a similar reaction.

As far as a final patch goes, we'd definitely need some tests to validate
that the model has, in fact, been overridden. I understand this is probably
a proof-of-concept patch - I'm just flagging it in case you thought "it
passes the current test suite" would be enough.

Yours,
Russ Magee %-)


On Sat, Feb 7, 2015 at 6:48 AM, Marten Kenbeek 
wrote:

> Hey,
>
> While fiddling with django I noticed it would be trivial to add support
> for shadowing fields from abstract base models. As abstract fields don't
> exist in the database, you simply have to remove the check that reports
> name clashes for abstract models, and no longer override the field.
>
> This would allow you to both override fields from third-party abstract
> models (e.g. change the username length of AbstractUser), and to override
> fields of common abstract models on a per-model basis. Previously you'd
> have to copy the original abstract model just to change a single field, or
> alter the field after the model definition. The first approach violates the
> DRY principle, the second approach can introduce subtle bugs if the field
> is somehow used before you changed it (rare, but it can happen).
>
> This patch
> 
>  adds
> the feature. It seems to work correctly when using the models and
> creating/applying migrations, and passes the complete test suite.
>
> What do you guys think about this feature?
>
> --
> 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/f846521f-8a16-41c7-9998-2bea7c93b3dd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Making the test suite run faster

[Russell Keith-Magee]

On Sat, Feb 7, 2015 at 12:05 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it
> faster by running tests in parallel.
>
> The current state of my experiment is here:
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module.
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>

Are you resource locking on anything else? e.g., is disk access becoming
the bottleneck? Even memory throughput could potentially be a bottleneck -
are you hitting disk cache?


> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests
> collide, for instance when they attempt to load the same fixture.
>

I've thought about (but never done anything) about this problem in the past
- my thought for this problem was to use multiple test databases, so you
have isolation. Yes this means you need to do more manual setup (createdb
test_database_1; createdb test_database_2; etc), but it means you don't
have any collision problems multiprocessing an on-disk database.


> ** Next steps **
>
> At this point, the patch improves the common use case of running
> `./runtests.py` locally to check a database-independent change, and little
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you
> have concerns about the implementation? Charitably, I’ll say that “it
> works”…
>

It's definitely worth pursuing. Faster test suite == double plus good.
Multiprocessing would seem to be an obvious approach, too.

My only "concern" relates to end-of-test reporting - how are you reporting
test success/failure? Do you get a single coherent test report at the end?
Do you get progress reporting, or just "subprocess 1 has completed; 5
failures, 200 passes" at the end of a subprocess? My interest here isn't
strictly about Django - it's about tooling, and integration of a
parallelized test suite with IDEs, or tools like Cricket.

Releasing it separately as a custom test runner may be more appropriate.
>

For me, it depends on how much code we're talking about, and how invasive
you need to be on the core APIs. If the multiprocessing bit is fairly minor
(and I suspect it probably is), but you need to make bunch of invasive
changes to the test infrastructure, then you might as well include it in
Django's core as a utility. However, if the whole thing can stand alone
with minimal (or no) internal modifications - or modifications that make
sense in a general sense - then you might as well release as a standalone
package.

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_P0eHmtmFh6WME_YnjSvVQ_G9UQHU1E3UrWeZw7%3DUApQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Elimination of limitations of bulk_create in Django

[Russell Keith-Magee]

Hi Elita,

On Fri, Feb 6, 2015 at 1:39 PM, Elita Lobo  wrote:

> Hello,
>
> I am a 3rd year student of NIT Durgapur , India as well as a Gnome
> Developer . I have worked on many Python projects as well. I would like to
> start contributing to django.
> Django does not allow bulk_create of objects with many_to_many field nor
> does it allow bulk update. Also it does not call save function which may be
> a bit of a problem if the save method has been overriden. I would like to
> work on finding a way around to eliminate these limitations.
>
> Kindly let me know if this is feasible and if I can submit a patch for the
> same.
>

Well, it's probably *feasible*, but not going to be *simple*.

If you exclude many-to-many fields, bulk_create() and update() can be
implemented with a single SQL call. If you allow m2m fields as well, you're
going to need at *least* 1+N calls, where N is the number of m2m fields.
I'm not saying it can't be done - prefetch_related has similar 1+N
mechanics. However, if you're looking for a simple first issue to tackle,
this probably isn't it.

Calling save() on update is a completely separate issue. Again, if you
follow the mapping from Django ORM API to SQL, you'll understand why save()
isn't invoked on update(), and why it would be difficult to make that
change.


> Also I would be grateful if you could point out a few bugs that could help
> me get started with contributing to django.
>

The list of all open tickets is here:

https://code.djangoproject.com/query

You can filter this on many different facets - e.g., a topic of interest
(database backend, template system); ticket status (e.g., patch needs
improvement); or, there's a flag for "easy pickings":

https://code.djangoproject.com/query?status=assigned&status=new&easy=1&desc=1&order=id

These are tickets that have been evaluated as "easy first tickets" by a
reviewer. That doesn't necessarily mean they *will* be easy - it's possible
that when you dig into the problem it will turn out to be more complex -
but at least on first inspection, they should be.

If you want to get involved contributing to Django, I'd also suggest
reading our contribution guide:

https://docs.djangoproject.com/en/1.7/internals/contributing/

This fills in a lot of details about how our development process works, and
has some other suggestions for how to get started contributing.

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_3La1id7KU2LCTAk38g-fgsGwoMwDEMkaE%2B5Mqs9RBqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Feature proposal: Allow shadowing of abstract fields

[Marten Kenbeek]

Hey,

While fiddling with django I noticed it would be trivial to add support for 
shadowing fields from abstract base models. As abstract fields don't exist 
in the database, you simply have to remove the check that reports name 
clashes for abstract models, and no longer override the field. 

This would allow you to both override fields from third-party abstract 
models (e.g. change the username length of AbstractUser), and to override 
fields of common abstract models on a per-model basis. Previously you'd 
have to copy the original abstract model just to change a single field, or 
alter the field after the model definition. The first approach violates the 
DRY principle, the second approach can introduce subtle bugs if the field 
is somehow used before you changed it (rare, but it can happen). 

This patch 

 adds 
the feature. It seems to work correctly when using the models and 
creating/applying migrations, and passes the complete test suite. 

What do you guys think about this feature?

-- 
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/f846521f-8a16-41c7-9998-2bea7c93b3dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the test suite run faster

[Michael Manfre]

Anything to make the test suite faster is a worthwhile effort. The speed up
will be even better for those of us with slower dev systems. Getting the
speed boost for in memory sqlite is a good start and Django is much more
than an ORM. It'll take work to improve the database isolation for the test
suite, but that is something that should probably happen regardless of
parallelization.

I'm imagining database backends being able to control whether or not they
support parallelization and if each process needs its own database.

Regards,
Michael Manfre

On Fri, Feb 6, 2015 at 11:05 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it
> faster by running tests in parallel.
>
> The current state of my experiment is here:
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module.
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>
> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests
> collide, for instance when they attempt to load the same fixture.
>
> ** Next steps **
>
> At this point, the patch improves the common use case of running
> `./runtests.py` locally to check a database-independent change, and little
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you
> have concerns about the implementation? Charitably, I’ll say that “it
> works”…
>
> Releasing it separately as a custom test runner may be more appropriate.
>
> What do you think?
>
> --
> 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/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBujE%2BJSs%2BiupVxWCcTKV5VcT7%3DmZw71DnaVODQDZ%3DqxuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: automated import sorting and better pull request checks

[Tim Graham]

isort has released a new version, so I've finished this task by merging the 
cleanups in Django and adding another pull request builder to verify isort 
doesn't complain on new changes. Documentation is available here: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#imports

Hopefully this allows contributors to more easily handle these fixes on 
their own in advance of a review from a human!

On Thursday, February 5, 2015 at 8:55:06 AM UTC-5, Tim Graham wrote:
>
> Two new builders run on all pull requests: 
>
>- ​flake8  - runs the equivalent of 
>flake8 from the root checkout directory and fails if there are any 
>warnings 
>- ​docs  - runs the equivalent of make 
>spelling from the docs directory and fails if there are any spelling 
>or sphinx errors.
>
> The spelling builder accidentally triggered on all open PRs so that's why 
> a lot of them appear as "pending."
>
> I've submitted a couple patches to isort and am awaiting a new release 
> there before continuing with that cleanup in Django.
> On Friday, January 30, 2015 at 5:22:27 AM UTC-5, Andrew Ingram wrote:
>>
>> For what it's worth, I prefer one import per line, if only because it 
>> makes diffs that involve changes to imports a lot easier to digest, and 
>> usually smaller.
>>
>> ie, something like this: 
>> https://gist.github.com/AndrewIngram/16da35699bd495f79adb
>>
>>
>> Andy
>>
>>
>> On 30 January 2015 at 09:36, aRkadeFR  wrote:
>>
>>>  I support the idea of introducing isort.
>>>
>>> Didn't know isort before and give it a try on personal project.
>>> It considers only the global import of the file (I mean on the
>>> very top on my files and not in the methods / functions). Which
>>> is exactly what it should do from my point of view.
>>>
>>>
>>> On 01/29/2015 02:18 PM, Tim Graham wrote:
>>>  
>>> As a code reviewer, I've really appreciated that we've cleaned up the 
>>> code using flake8 and have automated "enforcement" via the CI server. I'd 
>>> like to extend the idea to apply to standardizing import ordering using 
>>> isort [1]. This mail is to advise everyone of the change and to address any 
>>> concerns.
>>>
>>> Documentation:
>>> https://github.com/django/django/pull/4008
>>>
>>> Automated cleanups:
>>> https://github.com/django/django/pull/4009
>>>
>>> On a related note, the UI for flake8 errors isn't currently very good 
>>> (you have to look at the bottom of the Jenkins build logs). I'd like to 
>>> improve that by using a separate service that uses the GitHub status API 
>>> [2] so that the check can run separately from the tests build. I don't want 
>>> to reinvent the wheel though, so if there is an existing service we can use 
>>> for this, great. I'd like to also add checks for documentation build and 
>>> spelling errors, as well as isort checks (assuming adoption per above).
>>>
>>> [1] https://github.com/timothycrosley/isort#readme
>>> [2] 
>>> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>>>  -- 
>>> 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-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/d356e388-fa45-4fdf-871f-ce484a7b43bf%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>  -- 
>>> 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-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/54CB5092.90507%40arkade.info
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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-develope

Making the test suite run faster

[Aymeric Augustin]

Hello,

As the test suite is growing, it’s getting slower. I’ve tried to make it faster 
by running tests in parallel.

The current state of my experiment is here: 
https://github.com/django/django/pull/4063 


I’m distributing the tests to workers with the multiprocessing module. While 
the idea is simple, the unittest APIs make its implementation painful.

** Results **

Without the patch:

Ran 9016 tests in 350.610s
./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total

With the patch

Ran 9016 tests in 125.778s
./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total

Since it takes almost one minute to create databases, parallelization makes the 
execution of tests go from 6 minutes to 2 minutes.

This isn’t bad, but the x3 speedup is a bit disappointing given that I have 4 
physical / 8 logical cores. Perhaps the IPC is expensive.

Does anyone have insights about scaling with multiprocessing?

** Limitations **

This technique works well with in-memory SQLite databases. Each process gets 
its own copy of the database in its memory space.

It fails with on-disk SQLite databases. SQLite can’t cope with this level of 
concurrency. It timeouts while attempting to lock the database.

It fails with PostgreSQL (and, I assume, other databases) because tests 
collide, for instance when they attempt to load the same fixture.

** Next steps **

At this point, the patch improves the common use case of running 
`./runtests.py` locally to check a database-independent change, and little else.

Do you think it would be useful to include it in Django anyway? Do you have 
concerns about the implementation? Charitably, I’ll say that “it works”…

Releasing it separately as a custom test runner may be more appropriate.

What do you think?

-- 
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/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: ***SPAM*** Re: Middleware+Transactions:

[Thomas Güttler]

Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:

I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for given middleware, and
this makes it impossible to implement a transaction middleware purely
as a middleware.


It's the same with TestCase.setUp() and TestCase.tearDown() does not work
well together with decorators.

You are right. Instead of

 settings.MIDDLEWARES_INSIDE_TRANSACTION

 settings.CONTEXT_MANAGERS

would be better.

The atomic() could be one entry in the list of context managers.


An idea... Would investigating and implementing better middlewares (or
urlpattern wrappers) make for a good GSoC project? Maybe the "wrap
URLs" approach could be part of the URL resolve refactoring GSoC
project?


I don't know if GSoC is a good solution. It is appealing, since
it looks that someone else does the work (not me and my team mates).
But I am a little bit afraid that will this result in a more complicated
implementation. My perfect solution are only very few lines of code.
I guess this could be possible. I guess the diff for the docs
could be longer then the diff for the code.

Regards,
  Thomas

--
Thomas Güttler
http://thomas-guettler.de/

--
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/54D2260C.1050700%40tbz-pariv.de.
For more options, visit https://groups.google.com/d/optout.

Elimination of limitations of bulk_create in Django

[Elita Lobo]

Hello,

I am a 3rd year student of NIT Durgapur , India as well as a Gnome 
Developer . I have worked on many Python projects as well. I would like to 
start contributing to django. 
Django does not allow bulk_create of objects with many_to_many field nor 
does it allow bulk update. Also it does not call save function which may be 
a bit of a problem if the save method has been overriden. I would like to 
work on finding a way around to eliminate these limitations.

Kindly let me know if this is feasible and if I can submit a patch for the 
same. 
Also I would be grateful if you could point out a few bugs that could help 
me get started with contributing to django.


Thanking you,


regards,
Elita Lobo

-- 
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/a0e580de-7772-4f00-b710-fb3a23f9ebc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.