On Sat, Mar 2, 2013 at 11:38 AM, Per-Olof Åstrand wrote:
> First, I would like to give all my compliments to the persons that made
> Django what it is. Although my background is in scientific computing since
> 25 years back (using python, numpy, scipy, among other things), I came into
> contact wi
On Sat, Mar 2, 2013 at 12:50 PM, Ana Molf wrote:
> This function work under dev server but not ander prod
> Technical server contact said me that there are a problem because at SSH
>
>
Hi Ana,
You've posted this message to django-developers -- the mailing list for
people wanting to discuss the d
This function work under dev server but not ander prod
Technical server contact said me that there are a problem because at SSH
[28/Feb/2013 23:58:04] "GET /login/ HTTP/1.1" 200 15710
[28/Feb/2013 23:58:12] "POST /login/ HTTP/1.1" 500 6965
def login_test(request):
state = "Ingreso de usuario
First, I would like to give all my compliments to the persons that made
Django what it is. Although my background is in scientific computing since
25 years back (using python, numpy, scipy, among other things), I came into
contact with Django 0.91 in 2006 when one of my students used it in a
pr
On 1 March 2013 22:38, Alon Nisser wrote:
> at least from my windows exprience with Django (yes, I know this isn't a
> common use case, but still) the current django-admin.py and manage.py do
> need python preface to run right (while inside a virtualenv)
I'm not 100% sure if the Windows Python
at least from my windows exprience with Django (yes, I know this isn't a
common use case, but still) the current django-admin.py and manage.py do
need python preface to run right (while inside a virtualenv) - but maybe
I'm wrong, at least from my peak in Django setup.py It doesn't utilize
`entr
Hi,
On Friday, March 1, 2013 9:00:28 PM UTC+1, Luke Sneeringer wrote:
>
> I'd be interested in actually doing this if folks on the list think it's a
> good idea.
>
Doing it outside of Django core if fine, inside core is -0 to -1 from me.
Cheers,
Florian
--
You received this message because yo
I do think that there's a pretty common "alternate use case" which we could
support more easily. That's the use case where someone wants a User model that
is either:
* exactly like the Django User model, but with e-mail address as the unique
identifying field instead of username
* exactly lik
On Fri, Mar 1, 2013 at 1:25 PM, Alon Nisser wrote:
> and then it could be called as `django-admin somecommend` instead of `python
> django-admin.py somecommand`.
> since python (using setuptools entry points) makes making a python script
> into a shell script quite easy I guess this has been Discu
and then it could be called as `django-admin somecommend` instead of
`python django-admin.py somecommand`.
since python (using setuptools entry points) makes making a python script
into a shell script quite easy I guess this has been Discussed before but I
didn't find the discussion and the exp
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
[...]
> I don't see much point in providing an option to turn autocommit off,
> because starting a transaction is a much more explicit way to achie
On 1 maalis, 14:48, Aymeric Augustin
wrote:
> Yay or nay?
+1.
I discussed this on IRC with Aymeric. I tried to find cases where this
breaks currently working code, and I was mostly unsuccessful. It seems
there could be such cases (doing raw SQL writes, commit at end, and no
ORM writes, all this
On 2013-02-27 22:00:17 +, Alex Ogier said:
On Wed, Feb 27, 2013 at 4:42 PM, Aymeric Augustin
wrote:
On 27 févr. 2013, at 21:40, Marijonas Petrauskas
wrote:
Why isn't Pillow the recommended Django image library yet? PIL has
been unmaintained for almost 3 years and has a number of anno
Hey Aymeric -
Yes, I think this is the right thing to do: +1.
Jacob
On Fri, Mar 1, 2013 at 4:48 AM, Aymeric Augustin
wrote:
> Hello,
>
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
> ** Rationale
On Mar 1, 2013, at 4:48 AM, Aymeric Augustin wrote:
> Yay or nay?
+1.
--
-- Christophe Pettus
x...@thebuild.com
--
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 e
+1 from me. Here's a patch to add autocommit to MySQL:
https://github.com/django/django/pull/857
FWIW: any sort of scheme where a transaction is kept open all request
(including a transaction that only ever reads), will cause you serious pain
if you're trying to do migrations on MySQL with traffic
On 03/01/2013 05:48 AM, Aymeric Augustin wrote:
> Basically, Django intends to provide autocommit by default. Rather than
> fight the database adapter that itselfs fights the database, I propose
> to simply turn autocommit on, and stop implicitly starting and
> committing transactions. Explicit is
On 1 mars 2013, at 14:38, Javier Guerra Giraldez wrote:
> On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin
> wrote:
>> To alleviate the pain, Django commits after each ORM write.
>
> just curious: why is it so? i can't think of any reason not to tie
> transaction to the request/response cycl
On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin
wrote:
> To alleviate the pain, Django commits after each ORM write.
just curious: why is it so? i can't think of any reason not to tie
transaction to the request/response cycle by default. (ie what
TransactionMiddleware does).
this is the defa
Yay (+1) and preferably ASAP to get it tested by users right now.
--
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
On Friday, March 1, 2013 at 7:48 AM, Aymeric Augustin wrote:
> Hello,
>
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
> ** Rationale **
>
> PEP249 says that any SQL query opens a transaction an
Hello,
I'd like to improve transactions handling in Django. The first step is the
current emulation of autocommit with database-level autocommit.
** Rationale **
PEP249 says that any SQL query opens a transaction and that it's the
application's job to commit (or rollback) changes. This model
+1 for first and last
--
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 d
23 matches
Mail list logo
