Re: [Django] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
-+-
 Reporter:  Lynge|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 This is a subset of the general problem of multi-tenancy (#15089).

 The approach taken by the patch doesn't work because Django maintains
 internal caches that depend on the values of settings. If you change the
 active settings between two requests handled by the same Python process,
 these caches may hold stale values, with undefined results.

 The `settings_changed` signal might help, but it's only designed for tests
 at this time, and I'm not sure it covers all settings at this time.

 I'm going to close this ticket because I don't think the solution to
 multi-tenancy will come from hacks in the settings.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
---+
  Reporter:  Lynge | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Lynge):

 And now, 8 months later, I finally get around to looking at it.
 I am submitting a draft for, what I have called, ActiveSettings

 This is just meant to be a hook that will let external projects get a
 chance to change the settings as they are being requested.
 If this, or something like it, could be implemented, then I can just
 construct an external project that will let people solve this problem of
 sharding costumers and without getting in the way of anyone that will not
 be needing it, which I suspect is the largest part of the Django user-
 base.

 The diff is just a draft since this is my first contribution to Django, I
 thought I would post it for scrutiny before doing the docs and tests. I am
 sure there is a lot of errors in it, but the idea should be clear.

 Also, should I be taking this up on the mailing list? I read something
 about that in the contribution guide.

-- 
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-upda...@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.

Re: [Django] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
---+
  Reporter:  Lynge | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Lynge):

 I will look into your suggestion on the settings dictionary object
 replacement.

 On the subject of useful context information:
 I have found something called [http://github.com/svetlyak40wt/django-
 globals/ django_globals]
 It is very simple. It just uses threading.local() to store values, but if
 it will work everywhere I have no idea.

 I have been testing it on uWSGI with Cherokee in front and it seems to be
 behaving as one would want, but I have no idea if it is a viable method
 for any kind of setup. E.g. if it will share the values between requests
 in certain kinds of setups.

-- 
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-upda...@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.

Re: [Django] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
---+
  Reporter:  Lynge | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Someday/Maybe
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Accepting the use case; not necessarily sold on the proposed
 implementation approach.

 It might be possible to do right now by replacing the entire settings
 dictionary object with an object that implements the dict interface.

 The bigger issue will be getting access to useful context information
 (e.g., the domain where an request originates) to be able to shard on that
 basis. I'm not sure I see an easy way to get access to this data where it
 will be required.

-- 
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-upda...@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] #13053: Support for non-static DB connection info

[Django]

#13053: Support for non-static DB connection info
--+-
 Reporter:  Lynge |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 It would be great if we could specify a class or function as the source of
 the DB-connection information.

 I am thinking something like:

 {{{
 DATABASES = {
 'default': {
 'INFO_FINDER': 'myproject.myDBFinderApp.MyDBFinder',
 },
 'users': {
 'NAME': 'user_data',
 'ENGINE': 'django.db.backends.mysql',
 'USER': 'mysql_user',
 'PASSWORD': 'priv4te'
 }
 }
 }}}

 This would then get executed every time something was needed from the
 'default' DB.

 Where would this be useful?
 In my current project I am building a webapp where each client gets their
 own subdomain and is free to create users inside it. It would be very
 useful to shard data by this subdomain since my clients never have to
 communicate via the webapp. This means that I have to be able to create a
 new DB and connect to it whenever a new client signs up. This is not
 possible with the current setup using settings.py.

 This method of dividing clients is not new at all so I guess there is many
 more than myself that will benefit from this, but more importantly (I
 think) is that it will most likely cover any other corner-case that Django
 is not capable of, since it will be so easy to just write your own
 DBFinder and link it. Any DBFinder will, of course, have to always return
 the connection info in the correct format just like to one normally used
 in settings.

 I have tried to do it myself, but I just cant make any sense of it and
 have no idea where to do the check to see if settings give connection-info
 or just a place to get it.
 But I cannot imagine it would be any huge amount of work for the people
 who wrote the thing or just about anyone with greater skills in Django-
 development than my own.

-- 
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-upda...@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.