BigInt once more (and possibly last time) #399

d once for all. See also http://code.djangoproject.com/ticket/399#comment:44 Thanks for some response, TK -- Tomas Kopecek e-mail: permonik at m6.cz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Re: RWLock semantics (from ticket #6413)

Malcolm Tredinnick napsal(a): > > On Wed, 2008-06-25 at 11:54 +0200, Tomas Kopecek wrote: >> Hello, >> In django.utils.synch is located RWLock. When you try enter the same >> lock twice (probably in some subprocedure) you can't. I think that >> correct sema

RWLock semantics (from ticket #6413)

nt is to check lock if it is already locked for me. This is also impossible now. Example of this (possibly wrong) behaviour could be spotted in #6413. Don't we want to change semantics, or is this correct from django design view and should persist? -- Tomas Kopecek

Re: Question about queryset's iterator behaviour

IT clause in modified iterator() method. However you have to think about losing transactional behaviour, because one select via filter() or all() means many 'chunked' subselects. -- Tomas Kopecek

Re: Changes to request_response have broken django-rest-interface

Trac, it won't apply spam filtering to you. > > And how does one go about doing that? I don't see a signup link anywhere... > http://www.djangoproject.com/accounts/register/ -- Tomas Kopecek e-mail: permonik at

BigInt limitations and general dealing with db type definition

Append django-level validation of values and corresponding unit tests? -- Tomas Kopecek e-mail: permonik at mesias.brnonet.cz ICQ: 114483784 --~--~-~--~~~---~--~~ You received this message

Re: [Proposal] i18n blocktrans semantics & syntax change

Malcolm Tredinnick napsal(a): > On Thu, 2007-09-13 at 14:02 +0200, Tomas Kopecek wrote: > [...] >> I think that blocktrans in its current state is more obstacle than >> helper for me and introduces lot of quite unnecessary code. Furthermore >> I see priority in usab

Re: [Proposal] i18n blocktrans semantics & syntax change

since it's a bit restrictive. I'll try to dig it in the list. I think that blocktrans in its current state is more obstacle than helper for me and introduces lot of quite unnecessary code. Furthermore I see priority in usability and simplicity for designers than for translators. --

[Proposal] i18n blocktrans semantics & syntax change

%} declaration. I also think, that it is againstr DRY principle. -- Tomas Kopecek e-mail: permonik at mesias.brnonet.cz ICQ: 114483784 --~--~-~--~~~---~--~~ You received this message because you a

Re: [Fwd: Memory leaks]

Tomas Kopecek napsal(a): > Honza Král napsal(a): >> On 9/9/07, Tomas Kopecek <[EMAIL PROTECTED]> wrote: >>> Honza Kr�l napsal(a): >>>> can you replicate this with DEBUG=False in your settings? >>>> >>>> without DEBUG turned on, no querie

Re: [Fwd: Memory leaks]

ing really interesting in ORM layer. P.S. Maybe, this thread should be moved to django-users. -- Tomas Kopecek e-mail: permonik at mesias.brnonet.cz ICQ: 114483784 --~--~-~--~~~---~--~~ You

Re: [Fwd: Memory leaks]

Honza Král napsal(a): > On 9/9/07, Tomas Kopecek <[EMAIL PROTECTED]> wrote: >> Honza Kr�l napsal(a): >>> can you replicate this with DEBUG=False in your settings? >>> >>> without DEBUG turned on, no queries will be saved. I very much doubt >>&

[Fwd: Memory leaks]

st no change. Memory consumption continues. I've tested this problem with mysql and sqlite backend. The first one could be seen only with mysql and second with both of them. Has anybody any idea where to search for this leak? -- Tomas Kopecek