Re: 1.2 Proposal: Database savepoint refactoring
> 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 > do something to restore the DB connection to a usable state. With the patch > for #9205 would we be able to switch that to state that the app code will > never have to worry about clearing the error on the DB connection when it > catches a database error? If not then we would have less consistency than > before. Thanks Karen - that's an interesting take on the #9205 situation. I agree that our current situation is that "if your app code catches a database error it must do something to restore the DB connection to a usable state" and that is a consistent position. However, this need to "do something" is specific to PostgreSQL - on all other databases which I'm aware of the problem does not arise and the DB connection always returns in a usable state (someone please correct me if I'm wrong here...). That doesn't strike me as nice - effectively we end up with PostgreSQL- specific code in the app code. You can see many examples of this in the current test suite where various calls to create(), save(), etc. are wrapped in savepoints for the benefit of PostgreSQL only. This also makes it easy to write a Django app (or Django core code!) which tests and runs fine on other databases, but is buggy on PostgreSQL since these savepoint wrappers were omitted. I'd much prefer to move towards a uniform position of "the Django framework will always return a usable DB connection". We're already there on all non-PostgreSQL databases. We're already there on PostgreSQL for some calls (like get_or_create). I think that we can easily get there in the remainder (like create, save). Does this fix ALL cases where an IntegrityError results in an unusable PostgreSQL db connection? I'd need more work here to really believe this. Certainly I believe that we can get ALL wrapping uses of savepoints out of the test suite, which would be a practical demonstration of getting to or very close to this goal! Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Beta Thursday
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 (under "Small, or Just Bugs" and "Medium priority" respectively) and both have had working patches since January 1st or earlier. Thanks, Richard. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: SCRIPT_NAME/PATH_INFO, etc, changes
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 how Django should handle cases when PATH_INFO is not
set in the environment with which WSGI is called. The options are:
1) These are unusual cases, so Django should not handle this - "well,
then, don't configure your server that way".
2) If PATH_INFO is missing, Django should attempt to generate it from
other environment variables that may be present (e.g. REQUEST_URI).
Current behaviour is 1. I'd like to change to behaviour 2, since it
can't hurt - these cases just fail under behaviour 1 - and it will
succeed in some cases.
I've come across two cases in which PATH_INFO is not set:
1) SCGI + Cherokee (according to early discussion on #3414)
2) FastCGI + Lighttpd in an unusual configuration described on #3414
(this configuration was disliked by several commentators, but does
mirror the standard Rails + Lighttpd config at
http://github.com/rails/rails/tree/master/railties/configs/lighttpd.conf)
There are probably more cases with other webservers/configurations.
The patch to change to behaviour 2 is simple and self-contained. I
attach a version against [8015] below.
What do people think? I also have a similar patch for missing
QUERY_STRING when that should be there but isn't.
Richard.
--- a/django/core/handlers/wsgi.py(revision 8015)
+++ b/django/core/handlers/wsgi.py(working copy)
@@ -76,7 +76,10 @@
class WSGIRequest(http.HttpRequest):
def __init__(self, environ):
script_name = base.get_script_name(environ)
-path_info = force_unicode(environ.get('PATH_INFO', '/'))
+if environ.has_key('PATH_INFO') and environ['PATH_INFO']:
+path_info = force_unicode(environ['PATH_INFO'])
+else:
+path_info = force_unicode(environ.get('REQUEST_URI',
'/').partition('?')[0])
self.environ = environ
self.path_info = path_info
self.path = '%s%s' % (script_name, path_info)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Postgresql transaction aborts, despite being in autocommit mode
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 for a related problem.
I have a simple model:
class Test(models.Model):
data1 = models.IntegerField(unique=True)
data2 = models.IntegerField()
and a view using it:
def render(request):
a = Test()
a.data1 = 1
a.data2 = 10
a.save()
b = Test()
b.data1 = 1
b.data2 = 20
try:
b.save()
except IntegrityError:
# Expected since data1 not unique
pass
c = Test()
c.data1 = 2
c.data2 = 30
c.save()
return HttpResponse('Test')
All of this code is run without transaction middleware, which I
believe means that every database operation should auto-commit
individually, regardless of whether the database supports
transactions.
Correct behavior is for the view to return 'Test' and leave objects
'a' and 'c' in the database. I observe this on both MySQL with MyISAM
tables and MySQL with InnoDB tables (which supports transactions).
With Postgresql*, an internal error is raised by the line 'c.save()',
with the text 'current transaction is aborted, commands ignored until
end of transaction block'. Only object 'a' is left in the database.
I can work around the Postgresql behaviour by adding an explicit
savepoint and rollback around 'b.save()', but surely this should not
be necessary? I am operating in autocommit mode, so there should be no
transaction present. Equally, MySQL InnoDB does not require these.
I believe this boils down to the same issue as ticket [3460] - both
the psycopg1 and psycopg2 backends are using the wrong isolation
level, as a result of which the Django SQL is wrapped by psycopg
inside an implicit transaction. I have tried using the [3460] patch,
which gives me the Postgresql behaviour that I expected.
Your thoughts very much appreciated - assuming I understand the
meaning of "autocommit" this seems quite a fundamental problem.
Best regards,
Richard.
* My test is with Postgresql 8.1.4 and Psycopg2 2.0.7. However, if my
diagnosis is correct, then this will hold for all versions and also
for the Psycopg1 backend.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
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 which each individual change is committed independently and individually, and there is no transaction taking place. This is what I see from MySQL InnoDB. My problem is that I can't get this auto-commit behavior from PostgreSQL with Django - either in the default mode or even when I explicitly use TransactionMiddleware with the @transaction.autocommit decorator or set DISABLE_TRANSACTION_MANAGEMENT to True. My suggestion is that changing the psycopg isolation level to zero (as per ticket 3460) will give true auto-commit behaviour for PostgreSQL, since otherwise psycopg wraps the Django SQL in a transaction block. Note both psycopg1 and psycopg2 both provide an explicit function to switch them into autocommit mode by setting the isolation level to zero (search for 'autocommit' in http://www.initd.org/svn/psycopg/psycopg2/trunk/lib/psycopg1.py and http://www.initd.org/svn/psycopg/psycopg1/trunk/connection.c respectively). Cheers, Richard. On Sep 20, 12:12 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hi Richard -- > > What you've described is documented behavior for PostgreSQL (try > googling for "commands ignored until end of transaction block") -- > Postgres does not allow *any* commands in a transaction after a > database error; you have to commit or rollback first. > > Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
> 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 commit_unless_managed() calls inside the Django internals (e.g. inside save() ) - but a Django _user_ (rather than developer) would not have read this code before calling save(). So, a Django user who expects Python database adaptors to be non-autocommit is _already_ being surprised by the fact that save() behaves as if it is. By designing default Django behaviour to be "similar to auto-commit", I think we've already decided that the DB-API default is wrong. It's now a case of how Django implements the "similar to auto-commit" behavior most cleanly and efficiently. I think the answer is: - Get auto-commit connections from Python database adaptors by specifically requesting them - Delete all of the commit_unless_managed() calls - Change enter_transaction_management() / transaction.managed(True) to explicitly issue an SQL BEGIN - Change leave_transaction_management() / transaction.commit / transaction.rollback to explicitly issue SQL COMMIT / ROLLBACK I suspect that this will significantly simplify the Django codebase vs. trying to simulate both auto-commit and transaction behaviors on top of a transactional connection - it would certainly remove most of the mechanisms in django/db/transaction.py which track state, dirty, etc. Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
> > 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 > that makes them not require transactions? And more, how transactions -- > a mechanism for preventing DB to end up in an inconsistent state -- can > get you into error cases? On the first question, I'd suspect that many pages of many (simple) web applications just have a one-to-one mapping between the web page and a single line of SQL on a normalized database - e.g. a page listing all events (single SELECT), a page listing all people at an event (single SELECT), a form to add an event (single INSERT), etc. Wrapping these in transactions is pure overhead. On the second question, one example is my initial bug report starting this thread (admittedly PostgreSQL specific). Object 'c' is not saved when you would have expected it to be (and it is on other database backends). The problem isn't that transactions are bad in themselves, but that the code runs in a imperfect simulation of an autocommit environment on top of an implicit transaction (which the user would not be expecting). Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
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 example, a setting is > certainly the first step here. That's pretty independent of the whatever > the default might end up being. That's really the improvement needed to > #3460 at the moment -- separating adding functionality from changing the > default. ...and then repeated the point in a later mail, so I think that we should try to write a patch which a) makes 3460 a configuration option as suggested, and b) supports transactions on top of the autocommit connection when explicitly requested (3460 currently doesn't, so parts of the test suite currently fail when it is applied). I'd appreciate people's thoughts on the following proposal of how to do this. Particularly Malcolm, Jack and Collin since they seem the main contributors to date. 1) Mechanism to make it a configuration option Various people on the 3460 ticket tracker have suggested using [6064], but that isn't yet in trunk, and also wasn't generally agreed on the tracker (e.g. does not allow custom Python). So, let's not do that. We need two things - a way to create the backend in autocommit mode: I suggest a flag 'native_autocommit' for DATABASE_OPTIONS - a way for the running Django to tell that the backend is in autocommit mode: I suggest a flag 'uses_native_autocommit' for BaseDatabaseFeatures In both cases I'm deliberately choosing mechanisms and words so that other backends could also later be changed to support an autocommit mode. 2) Transaction support when explicitly requested The current 3640 patch leaves a Django which does not support any transaction behavior other than autocommit (leading to various test suite failures). The problem is that django/db/transaction.py also needs to be rewritten to actually create transactions (i.e. issue SQL BEGIN/COMMIT or BEGIN/ROLLBACK) on top of the connection when the user explicitly requests them. This is also a better and more general solution that the current hack to one specific case in loaddata, which could then also be removed. We'll essentially need two independent versions of transaction.py - the existing one for when Django runs on top of an implicit transaction, and a new one which actually creates transactions for when it doesn't. Implementations would be very different, but the interface and semantics can be identical, I think (except for rollback_unless_managed(), which cannot be supported, so would have to be removed from both versions and uses rewritten in some other form). I propose that we write the new version and test 'uses_native_autocommit' at the start of each function to decide which implementation to use. Malcolm: - You previously wrote: "This proposed change is a bit more complicated than the patches in #3460" - I do agree, but I think this is the only way to get 3460 to pass the transaction parts of the test suite! Do you see a simpler alternative? - You also wrote "The fact that none of the many patches on that ticket even touch save/update/delete handling has to be an error" - again I agree, but think that all of the required changes to save/ update/delete handling can be isolated away into transaction.py, as above. Do you see other problems? As I say, I'd appreciate people thoughts on this proposal - would this leave us with a patch for 3460 which will be accepted into trunk? Do people see problems/improvements to my proposal? This will be quite a bit of code for someone to write, so I'd like the design clear and agreed first. Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
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 ... is actually more efficient then equivalent in > auto-commit mode That's an interesting article, and I follow your logic. However, Jack's original patch follows from profiling work he did on his Chesspark site (see http://metajack.wordpress.com/2007/07/25/do-you-know-what-your-database-is-doing/ ) in which he claimed a 2-3x speed improvement from changing to auto- commit mode. I haven't done the equivalent testing myself, and would be interested in an explanation of why your article and his tests give such different conclusions. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
> 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 proposed a route forward http://groups.google.com/group/django-developers/msg/48500109ac5e514d and I'd much appreciate people (especially Malcolm, Jack, Collin, but others welcome too) replying to that message with their comments. There is an interesting side-discussion between Ivan/me/Jack/Michael, about whether the underlying Postgresql change actually improves performance. It would be great if someone can provide a simple test case demonstrating that it does. However, that's not the only reason to want the patch, so we should work towards a final patch anyway, and can benchmark that (on the test suite, say) once it's ready for check in. Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
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 thinking has changed during the course of the discussion. I now think that there are several people each feeling different pains (I was c, I think Jack was originally mostly b), and each believing that their particular pain would be solved by the same technical feature for Django. I'll call this feature 'native autocommit' - i.e. getting a connection from the database backend using the autocommit isolation level, and then creating explicit transaction blocks only when needed. What I'd like to do is step back from the pains for now, and produce a patch which adds an optional 'native autocommit' to the Django Postgresql backends. We'll see later which and how many of the pains it fixes, rather than arguing now. If it's very successful, maybe it will become the default behaviour for Postgresql and be implemented for other databases. If not, then at least the people who want it can simply turn the option on, rather than having to maintain out-of-trunk patches. Hopefully this is in the spirit of Malcolm Trediinnick's comment: > 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 example, a setting > is certainly the first step here. That's pretty independent of the whatever > the default might end up being. So, to reiterate. I'm thinking in terms of a new optional 'native autocommit' feature for the Django Postgresql backends. When the user chooses this option, the database connection which Django receives from the backend should be in "raw" autocommit mode, not wrapped in a transaction by the driver/backend, and Django would create explicit transaction blocks on top of this connection only when needed. I believe that this feature will require both: - Changes to the Postgresql backends to optionally return the autocommit connection - Changes elsewhere in Django (mostly db/transaction.py, I think), which notice when an autocommit connection is in use and then create explicit transaction blocks on top of this connection only when needed Please can we drop the discussion of pains for now, and just talk about how this new optional feature should best be implemented? My proposal is at http://groups.google.com/group/django-developers/msg/48500109ac5e514d - please read it mentally replacing 'ticket: 3460' with 'feature: option for native autocommit', then let's discuss! Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
I'm going to make one final post in this thread, since we didn't quite reach a conclusion. 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 example, a setting is > certainly the first step here. That's pretty independent of the whatever > the default might end up being. That's really the improvement 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 on top of the 'native autocommit' connection when explicitly > requested (the current 3460 patch doesn't, so parts of the test suite > currently fail when it is applied). Metajack wrote: > +1 from me So, do we agree that it makes sense for me to take the current 3460 patch and complete it in the manner which I described in http://groups.google.com/group/django-developers/msg/48500109ac5e514d ? I'd particularly like Malcolm to confirm if my description there matches his discussion with Collin. If we're agreed, then I'll take over ownership of that ticket from Collin (unless you want to do it, Collin?), and I'll add 'optional native autocommit' to the Django 1.1 features list. Cheers, Richard. One technical point: When I started writing in this thread, I hadn't appreciated that rollback() and rollback_unless_managed() are used by Django outside explicit user-started transaction management in order to attempt to keep things consistent after failures. How do people think that we should handle these when 'native autocommit' is on? The options seem to be: a) Make them no-ops and accept the failures b) Work out which points they roll back to, and add explicit 'BEGINs' at those points --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: 1.0.X branch created; trunk is open for features
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.0.1 release blockers?
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 subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: ModelForm.save() should implement force_insert and force_update, like Model.save()
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_insert will prevent overwriting existing data if the same primary key has accidentally been specified. I've previously opened ticket 8672 with a patch to add this feature. It got pushed to post-1.0, so I'd now like it to get into 1.1. The patch no longer cleanly applies against current trunk, but I will update it if people agree... Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: BigInt Patch for Django 1.0.2
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 to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Oracle savepoints
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 transaction gets broken by IntegrityErrors Savepoints were first implemented in Postgresql with [8314] last August, and were implemented for reason (b). Once a Postgresql transaction experiences an IntegrityError, it refuses all further commands with "current transaction is aborted, queries ignored until end of transaction block" until it has been rolled back to a prior savepoint (see http://groups.google.com/group/django-developers/browse_thread/thread/c87cf2d97478c068/ , http://docs.djangoproject.com/en/dev/topics/db/transactions/#handling-exceptions-within-postgresql-transactions) Are savepoints needed for this reason (b) in Oracle too, or are they simply there as a feature for users? i.e. does an Oracle transaction continue to function without savepoint rollback after an IntegrityError? Thanks, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle savepoints
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 for reason (a) to add the feature rather than reason (b) by necessity. But please can someone confirm? Thanks, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle savepoints
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 that savepoints are implemented (see BaseDatabaseWrapper._savepoint*() in django/db/ backends/__init__.py), and to signal that they are needed to wrap code which may throw IntegrityErrors (as per reason b; see QuerySet.get_or_create() in django/db/models/query.py). We should probably be splitting these two meanings, so Postgresql would have: can_savepoint = True needs_savepoint_after_exception = True Whereas Oracle would have: can_savepoint = True needs_savepoint_after_exception = False I'll open a ticket to remember this once Ian, Malcolm or another also confirms. Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Buildbot config for postgresql with database-level autocommit
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. We now also have the postgresql autocommit mode (http:// docs.djangoproject.com/en/dev/ref/databases/#autocommit-mode) and I'd like to get a buildbot running with those settings too. Should be easy - just duplicate the postgresql set up and additionally set the autocommit key. How can I help do this? Richard (Prompted by mir's comment on #10958) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Oracle savepoints
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
1.2 Proposal: Extra template tags and filters
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 add-ons. Here is my wishlist - please feel free to
comment on any others that you would like to see and on any of mine
where I've missed an obvious way to use the existing tags.
Filter: get
The built in dot (.) operator is great for accessing dictionary
lookup, attribute lookup, etc. However, it doesn't work when the
attribute/dictionary element is also a variable. I use a 'get' filter
with code like:
{% for k in keys %}
Value for {{ k }} is {{ d|get:k }}
{% endfor %}
where I'd like to just write d.k
I couldn't find another way, and often end up writing this operator,
so think that it or an equivalent mechanism should be built in.
Tag: ifstartswith
I find this very useful in writing menus, navigation bars, etc. since
I'm often checking whether the URL is within a given subdirectory.
Filters: sort and sortreversed
We have dictsort and dictsortreversed already, but what about sorting
simple lists? e.g.
{% for i in i_list|sortreversed %}
Yes, I could usually sort the list before passing it into the
template, but it's nice to be able to do it in the template at well!
Cheers,
Richard.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
1.2 Proposal: Database savepoint refactoring
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 are two reasons that they exist: 1) As a feature in their own right. 2) To work around database exceptions invalidating PostgreSQL transactions: http://docs.djangoproject.com/en/dev/topics/db/transactions/#handling-exceptions-within-postgresql-transactions At present, Django sometimes automatically uses savepoints in case 2, and sometimes expects the user to do so. I'd like to improve the consistency of this behaviour: 2a) Django already automatically uses savepoints inside some methods (e.g. QuerySet.get_or_create). This means that a database exception can never break the PostgreSQL transaction. Here there's an efficiency issue on Oracle - this use of savepoints should be PostgreSQL-specific, and isn't (see #11156). 2b) There are other similar methods, in which Django does not automatically use savepoints (e.g. QuerySet.create, Model.save) but in which database exceptions can easily occur and break the PostgreSQL transaction - for instance when saving a model with a conflict on a unique field. Here it's a consistency issue. To make things easy for the end users, I believe that Django should automatically add PostgreSQL-specific savepoints in these cases too, just like in QuerySet.get_or_create (see #9205). Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
