Opened 19 years ago

Closed 12 years ago

#409 closed enhancement (wontfix)

Add support for sqlrelay backend, to pool DB connections

Reported by: dustin@… Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version:
Severity: normal Keywords: database sqlrelay sql relay
Cc: Triage Stage: Ready for checkin
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

A discussion in the mailing list led to sqlrelay as being a good solution to limiting DB connections coming out of Django (among other benefits). I didn't see any activity over here, so I figured I'd open a ticket.

Attachments (1)

sqlrelaypg.py (7.1 KB ) - added by hugo 18 years ago.
first take at an sqlrelay backend for postgresql

Download all attachments as: .zip

Change History (6)

comment:1 by Adrian Holovaty, 19 years ago

Summary: sqlrelay backend supportAdd support for sqlrelay backend, to pool DB connections

by hugo, 18 years ago

Attachment: sqlrelaypg.py added

first take at an sqlrelay backend for postgresql

comment:2 by hugo, 18 years ago

I added a first take at a SQLRelay backend for Django, using the PostgreSQL database. This is actually needed per database, as SQLRelay will only handle some outer syntax itself (like using allways either :xxx or ? parameter style), but won't interfer with the SQL syntax itself. So sqlrelay actually is just another database driver for every database supported.

I did first tests with it and the basic stuff seems to work, but I do get weird hangups in sqlrelay. And if sqlrelay doesn't respond any more, the sqlrelay client libraries really go bozo - they took up a gigabyte of memory within only a few minutes. Don't know what exactly happened, as the sqlrelay debug logs are anything than helpfull (they just stop logging at one point in time, no mentioning what actually happens), but regardless of what did go wrong, they shouldn't eat up memory like they do. Even if I did configure the beast wrong, it shouldn't kill the machine.

So I am actually not that motivated to do more work on this, but attach the file nonetheless, so somebody else can take over from here.

Some caveat: postgresql connections start out with autocommit, that's why I send the BEGIN statement as the first statement, to switch them to transaction control (most postgresql drivers do that themselves, the sqlrelay driver doesn't). I used the DBAPI compliant sqlrelay driver, maybe better results and greater control could be gained by using the sqlrelay native API. Most work done was just setting up a wrapper for the cursor to turn parameter style into something sqlrelay requires. Otherwise it's just a copy of the postgresql driver with the type registry thrown out - maybe we would need additional code for handling datetime field types. Can't say myself, as I never reached a state where I could successfully play with those.

comment:3 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

Closing because we don't need this at the moment.

comment:4 by anonymous, 12 years ago

Easy pickings: unset
Resolution: wontfix
Status: closedreopened
UI/UX: unset

comment:5 by Aymeric Augustin, 12 years ago

Resolution: wontfix
Status: reopenedclosed

TicketClosingReasons/DontReopenTickets

This is better handled by external tools such as pgpool.

Note: See TracTickets for help on using tickets.
Back to Top