On Tue, Oct 29, 2013 at 4:29 PM, Robin Fordham wrote:
> What do you mean by this?
>
> By the nature of the data coming in it is pre validated, so I know already
> that row[0] is a valid id, row[1] is a valid foo value, row[2] is a valid
> baa value.
>
In case you were simplifying the example for
Hi Robin,
As far as I can tell, using one transaction should increase the
performance of the process. The reason is that you issue just one
COMMIT for the whole process instead of one per UPDATE. As an added
benefit, it helps with the data integrity.
There are two main ways I know you can improve
Thanks Tom, that clears things up a lot and gives me something to work on.
Sorry for the noob question;
If you cannot update the database without first creating the model
> instance - perhaps you need to call a method on the model instance in
> order to get one of the values to update, for exampl
On Tue, Oct 29, 2013 at 2:39 PM, Robin Fordham wrote:
> Hi,
>
> I have been doing some reading and am looking to increase the performance of
> updating existing database entries via incoming datafeeds.
>
> I am finding conflicting opinions if wrapping updates in a transaction
> context manager hel
Hi,
I have been doing some reading and am looking to increase the performance
of updating existing database entries via incoming datafeeds.
I am finding conflicting opinions if wrapping updates in a transaction
context manager helps improve performance, some sources say it does, others
say it
Hi Aymeric,
That's awesome, really appreciate you clarifying all of that! Look forward
to watching the video of your talk, the slides look great.
Cheers!
On Tuesday, 21 May 2013 17:43:00 UTC+1, Aymeric Augustin wrote:
>
> Hi Michael,
>
>>
>> *Django 1.5:*
>>
>
>>- The database-level auto
On May 21, 2013, at 12:43 PM, Aymeric Augustin wrote:
> Anyway, in this scenario, `atomic` will work as expected. When autocommit is
> off, you're always in a transaction, and as a consequence `atomic` uses
> savepoints to guarantee atomicity; it'll never commit. You have to call
> transaction.
Hi Michael,
>
> *Django 1.5:*
>
>- The database-level auto-commit is turned OFF.
>
> Yes.
>
>- SQL standards dictate that every query opens a transaction if one
>does not already exist. This happens regardless of the database's
>auto-commit setting.
>
> Yes, this is required
Regardless of whatever comments and corrections may come, I thank you for
summarizing what you think the changes will be! I didn't know about these
impending changes.
John
On May 21, 2013, at 4:23 AM, Michael wrote:
>
> I've been reading up on how transactions work in Django 1.5 and how they
I've been reading up on how transactions work in Django 1.5 and how they
will work in 1.6. I think I have a grasp of things, but I wanted to reach
out on here to just check that my understanding of things is correct, and
ask a question or two.
*Django 1.5:*
- The database-level auto-comm
On 8 June 2011 11:07, Marc Aymerich wrote:
> On Tue, Jun 7, 2011 at 11:53 PM, Malcolm Box
> wrote:
> > n 7 June 2011 15:16, Marc Aymerich wrote:You're
> right :) I'm using Mysql with myisam, I'm going to switch to
> InnoDB engine and try again.
>
> I thought that the transaction stuff were impl
On Tue, Jun 7, 2011 at 11:53 PM, Malcolm Box wrote:
> n 7 June 2011 15:16, Marc Aymerich wrote:
>>
>> Hi,
>> I've activated the
>> 'django.middleware.transaction.TransactionMiddleware' and I've
>> decorated one method with @transaction.commit_on_success
>> With this I expect that if the method ra
On Jun 7, 2011, at 7:16 AM, Marc Aymerich wrote:
> With this I expect that if the method raise an exception, django rolls
> back any database operation executed by this method, even the
> operations executed by submethods called by this main method, right?
That's correct.
> So I got this except
n 7 June 2011 15:16, Marc Aymerich wrote:
> Hi,
> I've activated the
> 'django.middleware.transaction.TransactionMiddleware' and I've
> decorated one method with @transaction.commit_on_success
> With this I expect that if the method raise an exception, django rolls
> back any database operation e
Hi,
I've activated the
'django.middleware.transaction.TransactionMiddleware' and I've
decorated one method with @transaction.commit_on_success
With this I expect that if the method raise an exception, django rolls
back any database operation executed by this method, even the
operations executed by
On Thu, Feb 11, 2010 at 8:55 AM, khoobks wrote:
> Hi Everyone,
>
> I was wondering if a Django guru was able to verify if my mental model
> of how django transactions operate is correct.
>
> The situation that I have is that I'd like to place the
> transaction.commit_on_
Hi Everyone,
I was wondering if a Django guru was able to verify if my mental model
of how django transactions operate is correct.
The situation that I have is that I'd like to place the
transaction.commit_on_success decorator around a custom function on my
model. At the same time, I would
17 matches
Mail list logo
