Re: Test optimizations (2-5x as fast)

[Ramiro Morales]

On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder  wrote:
> When I try this on a PostgreSQL database, I have problems relating to
> violated uniqueness constraints, sometimes from tests themselves, sometimes
> from setUpClass, sometimes from tearDownClass.  In the latter two cases,
> it's the sites table involved.  Is this something others have dealt with, or
> am I on my own? :)
>
> I tried adding a PostgreSQL "disable constraints" statement here:
> https://github.com/jbalogh/test-utils/blob/master/test_utils/__init__.py#L109
>
>    cursor.execute('SET CONSTRAINT ALL DEFERRED')
>
> It didn't help.

This might be related to ticket [1]#11665, a knownissue in the TestCase
handling of constraints with pg. Suggestion athere si to use
SET CONSTRAINTS ALL IMMEDIATE
before the rollback.

HTH

-- 
Ramiro Morales

1. https://code.djangoproject.com/ticket/11665

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test optimizations (2-5x as fast)

[Ramiro Morales]

On Fri, May 13, 2011 at 11:57 PM, Erik Rose  wrote:
> tl;dr: I've written an alternative TestCase base class which makes 
> fixture-using tests much more I/O efficient on transactional DBs, and I'd 
> like to upstream it.
> [...]
> 1. Class-level fixture setup
> [...]
> 2. Fixture grouping
> [...]

Only wanted to point that optimization of database data fixture loading
in tests is the topic of ticket [1]9449 in the Django bug tracker.

The two contributors that participated in the discussion there so far
took the fixture caching path, but I think the ticket can be considered
associated with the general problem and so is open for other solution
strategies.

-- 
Ramiro Morales

1. https://code.djangoproject.com/ticket/9449

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test optimizations (2-5x as fast)

[Erik Rose]

On Jun 5, 2011, at 10:18 AM, Ned Batchelder wrote:

> When I try this on a PostgreSQL database, I have problems relating to 
> violated uniqueness constraints, sometimes from tests themselves, sometimes 
> from setUpClass, sometimes from tearDownClass.  In the latter two cases, it's 
> the sites table involved.  Is this something others have dealt with, or am I 
> on my own? :)

Do you perchance have anything getting inserted into tables other than the ones 
explicitly mentioned in your fixtures, perhaps by a post_save signal? The code 
I have up at the moment doesn't deal with that. A cheap way to make it work 
would be to truncate *all* tables on teardown_fixtures (slow, ick).

I will be sure to give it a swing with Postgres; I hope to find time to work on 
the Django patch sometime this week.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Allow disabling choices in a

[Chris Beaven]

On Saturday, June 4, 2011 4:50:12 AM UTC+12, Jody McIntyre wrote:
>
> I can't think of a more concise way of clearly representing that 'bananas' 
> is disabled while still allowing it to have a label [...]
>

I'd say it would be more backwards compatible, and still reasonably concise 
to just have a separate attribute:

disabled_choices = ('bananas',)

-- 
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/-/NlVzSVQwYnU5Z3dK.
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.

Re: [GSoC composite fields] Weekly check-in #1

[Michal Petrucha]

All right, time for another check-in.

This isn't a lengthy one -- unfortunately last Tuesday my laptop
failed me, leaving me with no replacement, which means I have to wait
for it to return from the service center to be fully up and running.

In the meantime, I managed to borrow an old one a couple of days ago
but it isn't set up yet; I'm working on that. At least I can keep my
repo in sync with trunk at the moment...

Anyway, I hope the next update will be a more productive one. Until
then...

Michal

> [1] https://github.com/konk/django


signature.asc
Description: Digital signature

Re: support for custom django-admin commands written as packages

[Carl Meyer]

Hi Marwan,

On 06/05/2011 10:15 AM, Marwan Al-Sabbagh wrote:
> Hello,
>   Currently one can create a custom command by implementing a Command
> object in a python module such as
> "polls/management/commands/closepoll.py". It would be great if Django
> also supported these commands being implemented in a python package so
> in this case Command would be found in
> "polls/management/commands/closepoll/__init__.py". This would be
> useful when a command contains a lot of logic or code and the
> developer would like the ability to split up the logic into multiple
> files to make the code base more manageable. I faced this issue
> recently when I implemented a command that would be run as a cron job
> to periodically import data into Django from a legacy system that had
> some pretty hairy logic to deal with.
>I've already made the changes to support the feature, it only
> required a change to the function
> django.core.management.find_commands() to look for packages as well as
> modules in each commands directory. I thought I'd run it by
> django-developers before creating the ticket on trac with the patch.
> What do you guys think?

I'm not a big fan of the way Django finds management commands. Searching
directly on the filesystem makes Django apps with management commands
incompatible with legitimate builtin Python features such as import
hooks or zipfile imports. IMHO, regardless of what you think of those
Python features, this makes Django somewhat less than "just Python."

That said, I don't have a great alternative in mind at the moment, but I
don't like the idea of taking the current bad system and extending it
with even more complexity.

Generally my approach to the problem you describe is to make the
management command itself a minimal wrapper around the core code,
implemented as functions and classes within appropriately-named
submodules of the app itself, not within the
myapp.management.commands.mycommand namespace. I almost always at some
point want to reuse that code as library code, so I actually find it
preferable if the bulk of the code lives outside the management.commands
namespace, and is just imported and used by the management command. This
can also encourage a separation of responsibilities that makes testing
easier.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Preventing the leaking of sensitive information in error logs

[Julien Phalip]

Many thanks to all for the feedback. I've just posted a new patch,
welcoming any further feedback:
https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff

Regards,

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.