On Monday 31 March 2014 09:18:57 Anssi Kääriäinen wrote:
> On 03/30/2014 07:48 PM, Shai Berger wrote:
> > While fixing this, I ran into this line in the current docs:
> > """
> > Using select_for_update on backends which do not support SELECT ... FOR
> > UPDATE (such as SQLite) will have no effect.
Hi,
I was wondering if the test inputs in the validators tests should be given
as unicode or python string. It seems to me that at the moment the
validation is done, the string is already coded in unicode. However the
django tests use a python string as test input
(https://github.com/django/dj
Well, having stayed up til 4AM on Monday night, I managed to get the whole
book upgraded to Django 1.7, and published. I've shared some thoughts on
the migrations / tdd stuff we've been discussing, here:
http://www.obeythetestinggoat.com/book-upgraded-to-django-17.html
I'd be very interested i
On Wednesday 02 April 2014 13:43:23 alois.guill...@gmail.com wrote:
> Hi,
>
> I was wondering if the test inputs in the validators tests should be given
> as unicode or python string. It seems to me that at the moment the
> validation is done, the string is already coded in unicode. However the
>
On Thu, Mar 27, 2014 at 5:11 AM, VernonCole wrote:
> There was a recent query about prepared statements on the db-sig mailing
> list, too. Apparently thought is being given to adding such functionality to
> Psycopg.
This thread on the psycopg mailing list (and the linked, older
discussion and art
On Wednesday, April 2, 2014 6:58:22 AM UTC+3, schinckel wrote:
> For that reason, I wouldn't be the fan of the exploded syntax you've
>> given; I think I'd rather just be able to supply a list of strings for my
>> constraints that are SQL themselves; there's no real benefit to abstraction
>> he
As I've said on other threads, fields can't define extra operations - they
must do everything inside the SchemaEditor's add_field method (operations
are not the only thing which calls the SchemaEditor, in theory). Ticket
#22022 (https://code.djangoproject.com/ticket/22022) covers this - there'll
be
Hi everyone,
i'd like to start a discussion about multi tenancy on this list. I've
been asked to move the discussion here by Aymeric in this ticket:
https://code.djangoproject.com/ticket/17802
First we already have an initial patch sitting in this ticket:
https://code.djangoproject.com/ticke
On Thu, Apr 3, 2014 at 2:20 AM, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:
> Hi everyone,
>
> i'd like to start a discussion about multi tenancy on this list. I've been
> asked to move the discussion here by Aymeric in this ticket:
>
> https://code.djangoproject.com/ticket/1
> Short version - it doesn't matter what pretty name you put on it, a thread
> local is a global variable. We teach first year programmers not to use
> globals, so why would we introduce them to Django as a core framework idea?
>
Aren't database connections thread local in Django?
--
You rec
On Wed, Apr 2, 2014 at 7:42 PM, wrote:
>
> Short version - it doesn't matter what pretty name you put on it, a thread
>> local is a global variable. We teach first year programmers not to use
>> globals, so why would we introduce them to Django as a core framework idea?
>>
>
> Aren't database con
On Thu, Apr 3, 2014 at 7:42 AM, wrote:
>
> Short version - it doesn't matter what pretty name you put on it, a thread
>> local is a global variable. We teach first year programmers not to use
>> globals, so why would we introduce them to Django as a core framework idea?
>>
>
> Aren't database con
12 matches
Mail list logo
