Re: .rst files for tutorials of djangorocks.com

[Russell Keith-Magee]

Hi Gilberto,

The site you've referenced is not officially related to the Django project.
I wasn't previously aware of the site -- we'll be having words with them
for reproducing Django content without permission.

If you've got questions or comments about the tutorial, you'll have to take
that up with the owners of that site.

Yours,
Russ Magee %-)

On Mon, Apr 29, 2013 at 12:00 PM, gilberto dos santos alves <
gsa...@gmail.com> wrote:

> Hi for all.
>
> Following this url [1], i found some clarify needs for this tutorial works
> nice.
>
> Please where i find these .rst files? I already search django.github.comand 
> not found them.
>
> Thanks!
>
> url:: [1]
> http://www.djangorocks.com/tutorials/how-to-create-a-basic-blog-in-django/
>
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
>
>
>
>
>  --
> 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?hl=en
> .
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

.rst files for tutorials of djangorocks.com

[gilberto dos santos alves]

Hi for all.

Following this url [1], i found some clarify needs for this tutorial works
nice.

Please where i find these .rst files? I already search
django.github.comand not found them.

Thanks!

url:: [1]
http://www.djangorocks.com/tutorials/how-to-create-a-basic-blog-in-django/

-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django TestCase isolation: setUp vs setUpClass

[Russell Keith-Magee]

On Mon, Apr 29, 2013 at 4:08 AM, Danilo Bargen  wrote:

> Hi all
>
> Today I ran across an issue while debugging Django tests. As stated in the
> docs, all model changes in a TestCase that are done during the test are
> reverted between the tests. This creates a nice and useful isolation of the
> different tests. Each time a test runs, the database looks just the way it
> was after the syncdb.
>
> > from django.test import TestCase
> > from apps.front import models
> >
> > class Test1(TestCase):
> > def setUp(self):
> > models.User.objects.create(username='spamham')
> >
> > def test(self):
> > pass
> >
> > class Test2(TestCase):
> > def setUp(self):
> > models.User.objects.create(username='spamham')
> >
> > def test(self):
> > pass
>
> These test run fine, even though two users with the same PK are created,
> because Django handles test isolation. But things behave differently when
> using the setUpClass classmethod. I used setUpClass instead of setUp
> because there are certain models that I just want to create once for all
> the tests in a test case. It would be an unnecessary performance loss if
> those model instances were created and then rolled back for each test
> method. And less DRY.
>
> The problem is, model changes that are done in setUpClass aren't rolled
> back between the test cases.
>
> > from django.test import TestCase
> > from apps.front import models
> >
> > class Test1(TestCase):
> > @classmethod
> > def setUpClass(cls):
> > models.User.objects.create(username='spamham')
> >
> > def test(self):
> > pass
> >
> > class Test2(TestCase):
> > @classmethod
> > def setUpClass(cls):
> > models.User.objects.create(username='spamham')
> >
> > def test(self):
> > pass
>
> This fails with an IntegrityError due to a violation of
> the front_user_username_key unique constraint, because the User object from
> the first test wasn't removed.
>
> Is this a design decision? Or a technical limitation? (I realize that the
> use of a setup classmethod could cause issues with parallelization, but
> those issues could be addressed in the test runner.)
>

Neither really. It's an artefact of the history of Django's test framework.

The test framework was written almost 7 years ago, predating unittest2 by
several years. setUpClass was introduced by unittest2. As a result, the
infrastructure that resets tests after each setUp/tearDown pair hasn't been
modified to include setUpClass/tearDownClass as well.

I haven't looked at the problem in detail to establish if there is a
fundamental technical limitation preventing this; but off the top of my
head, I can think of a few complications that might pose difficulty. In
particular, the transaction rollback approach used to speed up fixture
loading won't adapt well to having two different 'setup' routines.


> And in the meantime, is there a better solution than to put all the common
> setup code in the setUp method?
>

Unfortuntately not.


> Note that I don't want to use fixtures for this. Fixtures are not a good
> way to create test data, as they're very static and need to be updated with
> the code. This also makes them error-prone. Instead I'm using Model Mommy (
> https://github.com/vandersonmota/model_mommy), a model factory library
> for Django. Another good alternative would be Factory Boy. These factories
> are also the reasons why I don't want to do manual cleanup in
> tearDownClass: First of all the model factory also creates related models
> that are needed to satisfy some foreign key constraints. I don't have
> references to all those model instances. And the second reason is that I
> think the database cleanup is something that Django should handle, not me.
>

If you want to avoid fixtures, Factory Boy would be my suggestion; I
haven't used Model Mommy myself, but it looks to be in much the same vein.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changing deferred model attribute behavior

[Shai Berger]

Hi again,

On Friday 26 April 2013, Anssi Kääriäinen wrote:
> [...]
> In almost every case it is better to try to minimize the amount of
> queries than the amount of loaded fields. The cases where you have
> deferred multiple fields, need only one of them later on, and there is
> a field that you can't load due to potentially huge value are
> hopefully rare.
> 
> But, I don't really care too much. If the objects come from DB queries
> instead of something like the use case of Adrian then if you end up
> doing deferred field loading you have already failed.

LOBs in Oracle always require at least a separate fetch operation to read 
them. Thus, you get an extra database hit per field (per record). Getting them 
before they are needed is almost always inefficient. As I already noted in this 
thread, they can even get in the way of query execution if not deferred.

I think it would be better if, at least on Oracle, such fields could be 
deferred by default. We are considering achieving this with an introspective 
custom manager, applied to all models (or at least all models with TextFields) 
in our project. If I could do it with a special field type, I would, and I'd 
recommend every other user do the same.

Just a data point for this discussion,

Shai.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changing deferred model attribute behavior

[ptone]

On Thursday, April 25, 2013 2:37:10 PM UTC-7, Anssi Kääriäinen wrote:
>
> On 25 huhti, 23:44, Alex Ogier  wrote: 
> > On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner <
> f.apollo...@gmail.com>wrote: 
> > 
> > > On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote: 
> > 
> > >> Also, I should mention that this should be *optional* behavior, as 
> the 
> > >> current behavior is reasonable for the common case. The API for 
> specifying 
> > >> this "load everything" behavior is a separate discussion. Perhaps a 
> keyword 
> > >> argument like: User.objects.only('username', loadall=True). 
> > 
> > > I could imagine a Meta attribute which introduces so called "deferred 
> > > groups" like SA has 
> > >http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#deferred-..., 
>
> > > accessing one column of a group will load all columns of the group. 
> Not 
> > > sure if we want that level of control, but I thought it would be worth 
> to 
> > > look what SA can do in this regard. 
> > 
> > I think groups are a very good abstraction for this problem. The two 
> common 
> > cases are probably "Load this column alone, because it's potentially a 
> big 
> > honking blob of text or binary" and "Load everything we don't have on 
> this 
> > object, because we are actually using it actively". Groups let you solve 
> > both problems flexibly. The downside is that they might not be very DRY, 
> > having to repeat group="everything" over and over if you just want to 
> load 
> > it all on first access. 
>
> +1 to this approach. 
>
> IMO load everything is a better default than one field at a time. When 
> deferred field loading happens something has already gone wrong. In 
> almost every case it is better to try to minimize the amount of 
> queries than the amount of loaded fields. The cases where you have 
> deferred multiple fields, need only one of them later on, and there is 
> a field that you can't load due to potentially huge value are 
> hopefully rare. 
>
> But, I don't really care too much. If the objects come from DB queries 
> instead of something like the use case of Adrian then if you end up 
> doing deferred field loading you have already failed. So, even an 
> error on deferred field access would work for my use cases of defer... 
>
>  - Anssi 
>

A couple just quick observations.

defer and only are tasks/concepts used when doing a query based on 
knowledge of your dataset - adding them to the model itself expands the 
number of places where this concept is considered. This has some good and 
some bad.

What happens if you have defined a group on a model, and use only a single 
field for 'only' in a QS? Does it fetch the only one I've asked for, or 
does it trigger the group?

Why couldn't one just defined the group in the code using .only() and pass 
all the fields at the time you want.

In Adrian's case, there will always be at least 2 DB hits - one could 
define the group of "lazy fields" and do something like:

>>> u = User.objects.only(*lazygroup).get(id=u.id)

I guess for something like that to be more practical, we need to expose 
something on the model instance that makes it easy to see what fields are 
currently deferred? Something that could easily check whether the second 
load had been done, and the lazy fields were available or not.

These are mostly observations, I'm not against adding the idea of groups to 
the model definition, but do think that if it can be solved at the scope of 
the QS usage, where .only() and .defer() currently are used, that would be 
better - one less reason to check the model definition to see how it was 
set up.

-Preston

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Django TestCase isolation: setUp vs setUpClass

[Danilo Bargen]

Hi all

Today I ran across an issue while debugging Django tests. As stated in the 
docs, all model changes in a TestCase that are done during the test are 
reverted between the tests. This creates a nice and useful isolation of the 
different tests. Each time a test runs, the database looks just the way it 
was after the syncdb.

> from django.test import TestCase
> from apps.front import models 
> 
> class Test1(TestCase): 
> def setUp(self):
> models.User.objects.create(username='spamham') 
> 
> def test(self):
> pass 
> 
> class Test2(TestCase):
> def setUp(self):
> models.User.objects.create(username='spamham') 
> 
> def test(self):
> pass

These test run fine, even though two users with the same PK are created, 
because Django handles test isolation. But things behave differently when 
using the setUpClass classmethod. I used setUpClass instead of setUp 
because there are certain models that I just want to create once for all 
the tests in a test case. It would be an unnecessary performance loss if 
those model instances were created and then rolled back for each test 
method. And less DRY.

The problem is, model changes that are done in setUpClass aren't rolled 
back between the test cases.

> from django.test import TestCase
> from apps.front import models
> 
> class Test1(TestCase):
> @classmethod
> def setUpClass(cls):
> models.User.objects.create(username='spamham')
> 
> def test(self):
> pass
> 
> class Test2(TestCase):
> @classmethod
> def setUpClass(cls):
> models.User.objects.create(username='spamham')
> 
> def test(self):
> pass

This fails with an IntegrityError due to a violation of 
the front_user_username_key unique constraint, because the User object from 
the first test wasn't removed.

Is this a design decision? Or a technical limitation? (I realize that the 
use of a setup classmethod could cause issues with parallelization, but 
those issues could be addressed in the test runner.)

And in the meantime, is there a better solution than to put all the common 
setup code in the setUp method?

Note that I don't want to use fixtures for this. Fixtures are not a good 
way to create test data, as they're very static and need to be updated with 
the code. This also makes them error-prone. Instead I'm using Model Mommy (
https://github.com/vandersonmota/model_mommy), a model factory library for 
Django. Another good alternative would be Factory Boy. These factories are 
also the reasons why I don't want to do manual cleanup in tearDownClass: 
First of all the model factory also creates related models that are needed 
to satisfy some foreign key constraints. I don't have references to all 
those model instances. And the second reason is that I think the database 
cleanup is something that Django should handle, not me.

Danilo

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Nested blocks in base template.

[Aymeric Augustin]

On 27 avr. 2013, at 11:05, Jonathan Slenders  
wrote:

> Is this documented? If so, then I need to fix it.

Maybe I'm biaised :) but that's the result I would expect.

What would you expect?

-- 
Aymeric.



-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Nested blocks in base template.

[Enrico B. da Luz]

Seems reasonable to me, the tool should try it's best to preserve the 
behaviour as much as possible, wheter it's documented or not.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.