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

[Kevin Tran]

Thomas, did you ever find a solution to your problem?  I'm having similar 
thoughts and am looking for an answer.

On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>
>
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c1ea2f8b-e976-4ef8-97e4-491a24ecc711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Kevin Tran]

I have found a good alternative to the old initial data feature.  It's 
called django-update-initial-data.

https://github.com/ambitioninc/django-dynamic-initial-data

MySQL compatible version:
https://github.com/minervaproject/django-dynamic-initial-data/tree/mysql

It's actually better than the old initial data feature because, "Django 
Dynamic Initial Data also handles when objects are deleted from initial 
data, a feature that Django's initial data fixture system lacks.".

On Tuesday, May 12, 2015 at 9:51:59 PM UTC-7, Pradeek J wrote:
>
> I'm facing the same speed issue here. Like Andrew mentioned above, if 
> initial data is going to be removed and data migrations are the way 
> forward, even having an option to skip migrations is a problem because we'd 
> need that data to be populated. Is there something planned for this for 
> Django 1.9? 
>
> On Saturday, December 27, 2014 at 8:10:10 PM UTC+5:30, Tim Graham wrote:
>>
>> In pull request 3791 , I 
>> started working on the code removals for Django 1.9 to better understand 
>> how the database/migrations code will look and what APIs we still need to 
>> deprecate. The good news is that we can keep support for apps without 
>> migrations (at least for Django's test suite) without adding any additional 
>> code or using any deprecated database creation APIs (as Claude suggested 
>> earlier). If you look at the commit "Removed supported for syncing apps 
>> without migrations" in that PR, you'll see "Run the syncdb phase" 
>> remains in the migrate management command, but now it'll only be executed 
>> when testing (and it's also quite a bit simplified due to other removals 
>> like support for initial data). It seems like it should be pretty simple to 
>> implement something similar to the old *SOUTH_TESTS_MIGRATE* setting in 
>> order to allow disabling migrations for all apps when testing if we wanted 
>> to go that route. I think the remaining deprecations to move forward with 
>> ticket 
>> #22340  (Legacy Table 
>> Creation Methods Not Properly Deprecated) are straightforward and will 
>> leave a comment there about it.
>>
>> On Saturday, December 20, 2014 2:18:17 PM UTC-5, Aymeric Augustin wrote:
>>>
>>> There's django-admin test --keepdb for this purpose (in Django 1.8).
>>>
>>> -- 
>>> Aymeric.
>>>
>>> Le 20 déc. 2014 à 18:41, Bernard Sumption  a 
>>> écrit :
>>>
>>> A proposition: the problem isn't that migrations take 80 seconds, it's 
>>> that this 80 seconds is repeated every time a developer runs tests. How 
>>> about serialising the structure and content of the database to disk after 
>>> applying migrations, then whenever you need a migrated test database, load 
>>> it from disk unless the migration files have been altered since the 
>>> serialised version was created?
>>>
>>> Bernie :o)
>>>
>>> On 20 December 2014 at 10:52, Andrew Godwin  wrote:

 Clause, I believe that line is to allow people to run makemigrations 
 when AUTH_USER_MODEL points to an app that doesn't yet have migrations; 
 before, it would fail hard, as the AUTH_USER_MODEL was not in the migrate 
 state and so nothing could use it, and you couldn't run makemigrations to 
 create it as it would error out.

 I'd test variations of that to see if your patch still works; if not, 
 we'll need a workaround again.

 Andrew

 On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz  
 wrote:
>
> On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>>
>> Yes. Claude has worked on the deprecation in 
>> https://github.com/django/django/pull/3220 but it requires adding 
>> more migrations to our test suite and he noted that each migration we 
>> add 
>> to Django's test suite adds up to ~3.5 seconds to the run time of the 
>> test 
>> suite. He also worked on some speed ups to mitigate this in 
>> https://github.com/django/django/pull/3484 but there are some 
>> unsolved issues.
>>
>
> I think that the first mentioned patch I worked on (PR 3220) shows 
> that it should be possible to use the new schema infrastructure without 
> requiring migrations, at least for apps that don't depend on other 
> migrated 
> apps. Tell me if I miss anything.
>
> But surely, I'd really like to solve first the speed issue of 
> migrations (#23745, PR 3484). Chris, if you have the opportunity to test 
> that patch with your database, it would be great. The way forward for 
> this 
> patch is to first test the "if app_label == settings.AUTH_USER_MODEL 
> and ignore_swappable:" line which is currently not tested and is 
> probably not addressed by my patch. Andrew, do you remember why you 
> introduced that part of the code?
>
> Claude
>
> -- 
> You received 

Re: Template Engine Compilation and Runtime Refactoring Progress

[Kevin Tran]

Has the repository been 
deleted? https://github.com/mitsuhiko/django-template-compilation is giving 
me a 404.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qccEQSWqb7sJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.