Code

Opened 9 years ago

Closed 2 years ago

#409 closed enhancement (wontfix)

Add support for sqlrelay backend, to pool DB connections

Reported by: dustin@… Owned by: adrian
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 8 years ago.
first take at an sqlrelay backend for postgresql

Download all attachments as: .zip

Change History (6)

comment:1 Changed 9 years ago by adrian

  • Summary changed from sqlrelay backend support to Add support for sqlrelay backend, to pool DB connections

Changed 8 years ago by hugo

first take at an sqlrelay backend for postgresql

comment:2 Changed 8 years ago by hugo

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 Changed 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:4 Changed 2 years ago by anonymous

  • Easy pickings unset
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • UI/UX unset

comment:5 Changed 2 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from reopened to closed

TicketClosingReasons/DontReopenTickets

This is better handled by external tools such as pgpool.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.