Re: [Django] #15131: pg_service.conf support

[Django]

#15131: pg_service.conf support
---+
  Reporter:  valczir.darkv...@gmail.com| Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.2

Resolution:  wontfix   |  Keywords:  
postgresql, pg_service, pg_service.conf
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => wontfix
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I'm not sure I see the benefit here. It's certainly nice that Postgres
 provides a way to perform the abstraction that you describe, but I'm not
 sure I see the advantage that is gained by having Django support it. It
 would be a configuration scheme that only works for Postgres -- no other
 backend (that I'm aware of) has an analogous configuration scheme. This
 means that the cross-database nature of Django would be somewhat
 compromised -- we would have a DATABASES setting that only works for
 Postgres.

 Closing wontfix; please start a discussion on django-dev if you feel
 strongly about this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15131: pg_service.conf support

[Django]

#15131: pg_service.conf support
-+--
 Reporter:  valczir.darkv...@gmail.com   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Database layer (models, ORM) | Version:  1.2   
 Keywords:  postgresql, pg_service, pg_service.conf  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 In PostgreSQL, there is a config file, pg_service.conf, that allows one to
 define shortcut names to connection parameters.  This makes it easy to
 migrate a database without having to mess with individual application
 configurations - just change the pg_service.conf file and you're done.

 I've managed to get it working, although I'm not sure this is the right
 way to do it.  Unfortunately, as far as I know, psycopg2 only supports a
 service name in a dsn string, not as a connection param, so I've had to
 run a completely separate connect() for pg_service.  However, as a service
 name in pg_service.conf defines all of the other connection options, I
 don't think it's a large problem; it just bothers me that they need to be
 separate.

 I'm also not sure how best to handle the case where there is a service
 name and also normal db connection params.  On my side, since we're using
 pg_service for nearly everything, I've just got it ignoring normal
 connection params if a service name exists.

 Anyway, a diff between my a/base.py and b/base.py (a being the original
 django/db/backends/postgresql_psycopg2 directory, b being the copy of a
 where I was doing my changes) is attached, more to show what I did than as
 a suggested patch - this was just a quick hack thrown together to get
 things working for me.  The version of django I was editing was 1.2.4, I
 believe (python26 manage.py --version shows 1.2.4, at least).  I've tested
 both with a service and with the original connection params, and it seems
 to work.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.