On Sun, 2008-11-16 at 17:14 -0800, Matthew D. Hancher wrote: > Hi all, > > I've been playing with adding sqlite3 back-end support to GeoDjango, > using the SpatiaLite extension. This requires executing some magic > SQL each time you connect to the database, to enable the spatial > extensions. Ticket #6064 seems like this right way to do this, by > causing the database to send a signal each time a new connection is > opened, which GeoDjango can catch. This works like a charm, and I > just uploaded an updated patch to that ticket, since it hadn't been > touched for a year and had gotten quite stale.
Modulo my question about signal overhead below, this seems like a decent approach. It's kind of the reason for signals existing. A random thought: is there any other information worth sending along with the signal? Right now, the receiver is told "a connection was created". Anything that's likely to vary and that could be useful as a trigger for other actions? I can't immediately think of anything, but I'll throw it out there in case I've overlooked something. > I'm curious if anyone thinks there's a better way to do this (i.e. > cause magic SQL to be executed on each database connection). I'm also > curious whether the test in my patch passes for other back-ends, like > oracle and whatnot. > > Finally, it occurred to me that a signal on *cursor* creation could > also be useful, and could easily be added at the same time. (In fact > in the old patch the connection_created signal actually erroneously > behaved like a cursor_created signal for some back-ends.) I'm not up to speed these days on the overhead for signal emission. We create a lot of database connections, for better or worse (as you no doubt realise, our connection management strategy is "one per request"). Is the impact noticeable for those doing nothing with the signals? I suspect it's not hard to test, but I'm going to be lazy and not do it myself (I suspect my laptop isn't quite production-quality hardware in any case). I'm generally in favour of the idea, though. Looks like a reasonable use for signals and your use-case seems like a typical situation that will need this. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
