On May 12, 2:41 pm, Michal Petrucha wrote:
> Due to the nature of this field type, other lookup filters than
> ``exact`` and ``in`` would have unclear semantics and won't be
> supported. The original plan was to also exclude support for ``in``
> but as it turns out, ``in`` is used in several place
There's a related, ongoing discussion here:
http://code.djangoproject.com/ticket/13906
It looks like the general attitude is that MySQL backend should switch to
READ COMMITED isolation level,
which would be the simplest solution.
Tomasz
--
You received this message because you are subscribed t
I know this has been discussed (not sure to what depth) but callables is not
the solution. Please bear with me and help me (not force me) to understand why
what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the ticket
system. http://code.djangoproject.
I know this has been discussed (not sure to what depth) but callables
is not the solution. Please bear with me and help me (not force me) to
understand why what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the
ticket system. http://code.djangoproject.com
On 5/16/2011 11:18 PM, Erik Rose wrote:
How about caching the test databases? The database state could be cached after
model setup (which takes some time if you've got lots of them) + initial data
fixture setup, and after the setup for each test case (fixtures + setUp()
method).
So, in the be
On 17/05/11 12:20, Anshuman Aggarwal wrote:
> Since the parent__child syntax is being used for list filter, search
> fields and everywhere else, is there a reason why the list_display has
> to be sacrosanct?
Please see my response on Trac - I didn't notice you had brought this up
here, so posted t
Check the path output in unittests are difficult, if a form widget
should be checked.
The Problem:
The widget html attribute order is not contingent and may change from
test to tests, because they come from a python dict witch is
unordered...
A simple patch could fix this, by adding sorted() to
f
I had seen it on trac (since I am following that ticket which has been
marked closed).
I got a mail to not open tickets closed by the core team and to take
up the discussion here. I am putting my reply to your comment here and
keeping the discussion on this thread for resolution.
list_display ope
On 05/17/2011 01:55 PM, Ned Batchelder wrote:
On 5/16/2011 11:18 PM, Erik Rose wrote:
How about caching the test databases? The database state could be
cached after model setup (which takes some time if you've got lots of
them) + initial data fixture setup, and after the setup for each test
case
On Tue, May 17, 2011 at 02:05:10AM -0700, akaariai wrote:
> On May 12, 2:41 pm, Michal Petrucha wrote:
> > Due to the nature of this field type, other lookup filters than
> > ``exact`` and ``in`` would have unclear semantics and won't be
> > supported. The original plan was to also exclude support
On Tue, May 17, 2011 at 9:16 AM, Jonas H. wrote:
> Invalidation is what I'm unsure about too -- multiple ideas came to my mind,
> all involving some sort of Great Hash(tm):
Even within a single test command run, the same DB setup and same
fixture loads are done many times (for a sizable suit
On Mon, May 16, 2011 at 10:12 PM, David Cramer wrote:
> Postgres requires resetting the sequences I believe. I just assume
> Oracle/MSSQL are probably similar.
Actually in the Oracle backend, resetting the sequence for an empty
table is currently a no-op for transactional reasons.
--
You receiv
On May 17, 5:32 pm, Michal Petrucha wrote:
> Proper subquery support is something that can be addressed once the
> rest of the implementation is stable.
To me the plan looks very reasonable (both disallowing subqueries and
converting to disjunction form), unless there is some part in the
internal
On 5/17/2011 10:48 AM, Jeremy Dunck wrote:
On Tue, May 17, 2011 at 9:16 AM, Jonas H. wrote:
Invalidation is what I'm unsure about too -- multiple ideas came to my mind,
all involving some sort of Great Hash(tm):
Even within a single test command run, the same DB setup and same
fixture loa
On Tue, May 17, 2011 at 10:24 AM, Ned Batchelder wrote:
> Maybe it wouldn't be so bad to punt on invalidation? The cached databases
> would only have to be rebuilt if the models changed or if the fixtures
> changed, right? We have a similar situation now with migrations: you have
> to write one
On Fri, May 13, 2011 at 10:10 AM, Jannis Leidel wrote:
...
> I've added something related the other day in changeset 16165.
>
Following up here, Jannis added a patch to a sort-of related ticket:
http://code.djangoproject.com/ticket/15561
This refactors the context manager into also supporting us
On 17.05.2011, at 17:41, Jeremy Dunck wrote:
> On Fri, May 13, 2011 at 10:10 AM, Jannis Leidel wrote:
> ...
>> I've added something related the other day in changeset 16165.
>>
>
> Following up here, Jannis added a patch to a sort-of related ticket:
> http://code.djangoproject.com/ticket/15561
On 5/17/2011 11:31 AM, Jeremy Dunck wrote:
On Tue, May 17, 2011 at 10:24 AM, Ned Batchelder wrote:
Maybe it wouldn't be so bad to punt on invalidation? The cached databases
would only have to be rebuilt if the models changed or if the fixtures
changed, right? We have a similar situation now w
On Tue, May 17, 2011 at 11:01 AM, Jannis Leidel wrote:
>> I was looking more for transaction rollback semantics -- rather than
>> overriding (and then restoring) specific settings, I was hoping for
>> settings to be set back just as they were before the test.
>
> Yah, but the good news is that the
On Tue, May 17, 2011 at 6:42 PM, Jeremy Dunck wrote:
> On Tue, May 17, 2011 at 11:01 AM, Jannis Leidel wrote:
>>> I was looking more for transaction rollback semantics -- rather than
>>> overriding (and then restoring) specific settings, I was hoping for
>>> settings to be set back just as they w
On 05/17/2011 04:48 PM, Jeremy Dunck wrote:
1) Use file modification timestamps for all model and test related files.
Advantages: simple, works.
Disadvantages: Triggers cache invalidation for changes not related to models
or tests
I think this is a pretty big win, even though it's not theoretic
> I declare myself bike-shedding. Given the 3 options, I'm:
>
> +1 on #1
> +0 on #2
> -0 on #3
Heh, I was just going to quietly sit here and do that while everybody else kept
mailing. :-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
On Tue, May 17, 2011 at 12:59 PM, Jonas H. wrote:
> On 05/17/2011 04:48 PM, Jeremy Dunck wrote:
>>>
>>> 1) Use file modification timestamps for all model and test related files.
>>> Advantages: simple, works.
>>> Disadvantages: Triggers cache invalidation for changes not related to
>>> models
>>>
> I would be very happy to test this against Oracle database to see is how
> much patch improves speed since previously running tests against Oracle
> has been a real pain specially all db recreate stuff took a long long
> time.
Great! I'll post again to this thread when the patch is ready. Or, if
On May 17, 2011, at 7:16 AM, Jonas H. wrote:
> 3) Hash the SQL generated for setup/fixtures. (step in right before the SQL
> is sent to the database)
> Advantages: No false-positives, simple
> Disadvantages: Does not eliminate the need for SQL generation and fixture
> parsing + model creation, s
Hi Anshuman,
On 17/05/11 14:42, Anshuman Aggarwal wrote:
> list_display
> allows for callables and hence arbitrary names can be used which are
> similar to the syntax for foreign key fields.
> However, this problem exists for list_filter also: someone may define
> a
> field with the name class__f
Is there a sensible to way "copy" databases in SQL? it's pretty
obvious with things like sqlite, but outside of that seems tricky. I
really like that idea, and you should definitely just be able to (at
the very least) run a unique hash on the required fixtures to
determine if a database is availabl
> Is there a sensible to way "copy" databases in SQL?
SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table.
It's supported in MySQL at least. You could then do a bunch of INSERT INTO ...
SELECTs if you deferred foreign key checks first.
Wait, why do you want to?
--
You
On Tue, May 17, 2011 at 6:46 PM, Erik Rose wrote:
>> Is there a sensible to way "copy" databases in SQL?
>
> SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table.
> It's supported in MySQL at least. You could then do a bunch of INSERT INTO
> ... SELECTs if you deferred for
29 matches
Mail list logo
