On Feb 2, 9:19 pm, James Bennett wrote:
> Also, note that this will be the final feature freeze for 1.2;
> if it ain't in trunk when I roll the tarball, it'll have to wait until 1.3.
Any chance of getting #10476 and #11156 in?
Both minor features, but both on the Version1.2Feature wiki page
(und
> I don't agree the current savepoint use within Django is inconsistent. As
> far as I can tell, savepoints are used internally in the one case where
> Django itself catches and suppresses an IntegrityError.
...
> Right now it is pretty simple: if your app code catches a database error it
> must
Hi all,
I've got two open tickets against database savepoints (#11156 and
#9205) and think this is an area which we should take a look at for
1.2 - it is currently inconsistent, IMHO.
Savepoints are described here:
http://docs.djangoproject.com/en/dev/topics/db/transactions/#savepoints
There a
Hi all,
With 1.1 out of the door (great!), here's a thought for 1.2...
I often end up writing the same couple of template tags and filters. I
think some of these are general enough and useful enough that they
should be considered for basic Django 1.2, even though they're fairly
easy to write as
On May 18, 5:12 pm, Ian Kelly wrote:
> Yes, it was reason a). Transactions aren't automatically invalidated
> after an IntegrityError, as far as I was able to determine.
Thanks Ian. Ticket #11156 records the current inefficiency on Oracle.
Cheers,
Richard.
--~--~-~--~~~
Hi all,
I'm wondering how to add a configuration to Leo Soto's Hudson buildbot
at http://testing.ingenium.cl/hudson/job/django-trunk/ ? (Assuming
that this is the canonical buildbot and that it is still in use!)
At present it seems to run with settings for sqlite3, mysql,
postgresql and oracle.
Matt Boersma wrote:
> I think Malcolm implemented this in the Oracle backend rather than Ian
> K. or myself.
It was Ian Kelly, I think in [10022].
> So I'd say the answer is a).
If that's right, then we have an inefficiency on Oracle at present -
the uses_savepoints flag is used both to signal
My question is effectively the same as asking if the test suite passed
on Oracle between [8314] in August 2008 and [10022] in March 2009.
I assume that it must have passed during those six months (Django 1.0
was [8961] in September 2008!), which would imply that Oracle
savepoints were implemented
Calling any Oracle developer (Matt Boersma?, Ian Kelly?),
I see that the Oracle backend has had savepoint support since [10022]
in March.
I'd like to understand whether this was done:
a) simply to add the feature (which is good!)
b) "by necessity" to be able to perform savepoint rollback when a
Ticket 399 has various patches.
Not clear to me why none of these have been merged for 1.1 yet?
Richard.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
The title says it all!
[8267] added the ability to force an SQL insert (or force an update)
via a model's save() method.
I would like the same force_insert and force_update flags to be
supported in a modelform's save() method.
These flags enable better control over some edge cases - e.g.
force_
I would like to nominate:
http://code.djangoproject.com/ticket/8754
http://code.djangoproject.com/ticket/9206
Both have patches which still apply, and just haven't been reviewed
yet.
Richard.
--~--~-~--~~~---~--~~
You received this message because you are subscri
Great!
Perhaps it's now time for a '1.0.1' milestone in the ticket tracker,
to nominate those tickets which are simple bug fixes against '1.0'?
Clearly still too early for '1.1' milestone, etc, given that there's a
different process started for that
Cheers,
Richard.
--~--~-~--~
ovement needed to
> #3460 at the moment -- separating adding functionality from changing the
> default.
Richard Davies wrote:
> I think that we should try to write a patch which a) makes 'native
> autocommit' a configuration option as suggested, and b) supports
> transactions
Michael Radziej wrote:
> There is no way to agree about the "#3460 ticket", because the ticket does
> not really state what you want to solve, but how you want to change Django.
...
> Now, please, pick only one pain
I certainly agree that we've been all over the place on this thread!
And my think
> Can we figure out what this thread is about, and stick to it, please?
As the person who originally started the thread ;-)
I'd like to agree a design for a patch which will be accepted into
Django trunk and will enable us to close the #3460 ticket.
The current #3460 patch needs more work. I've
Ivan Sagalaev wrote:
> When it comes to overhead... As far as I know PostgreSQL in autocommit
> mode will wrap each statement (even SELECT) in an implicit transaction.
>
> http://it.toolbox.com/blogs/database-soup/postgresql-application-performance-tips-part-1-13172
...
> So what Django does now .
Malcolm Tredinnick wrote:
> As I mentioned to Collin at the code sprint in Portland, I think it'd be
> a good idea to make sure we expose the ability to turn on auto-commit,
> but I don't really like making it the default. In any case, providing
> the ability that's can be controlled via, for exam
> > It is also highly inefficient for Web applications (since
> > they most often do nothing transactional) and gets you into trouble in
> > error cases.
>
> I don't want to get into the argument about ticket 3460 itself but I
> just don't get this paragraph... What is special in web applications
> One reason not to do this is that it simply isn't standard behaviour for
> Python database adaptors (they must be in non-autocommit mode
> initially). So there's a principle of least-surprise thing going on.
I'm not convinced by the argument of least-surprise. As you said,
there
are explicit co
Hi Jacob,
I agree that this is documented behavior for PostgreSQL
_transactions_.
The reason that I think it's a bug is that I shouldn't be in a
transaction at all - as I understand
http://docs.djangoproject.com/en/dev/topics/db/transactions/
, the default behaviour should be auto-commit in whi
Hi all,
I believe that I have found a bug in Django 1.0 for both Postgresql
backends, but would very much appreciate your thoughts in case I am
misunderstanding something... The test case seems clear enough that
this must have been noticed before, and there is an existing open
ticket and patch fo
First of all, thank you very much to Malcolm for fixing this - clearly
a massive step forwards towards 1.0!
I've subsequently had a discussion on the #3414 ticket tracker, which
I'm now moving to django-developers before it becomes too lengthy, as
per the "How to contribute".
The question is ho
23 matches
Mail list logo
