Re: Multiple database support
On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote: > 1. Replication - being able to send all of my writes to one master > machine but spread all of my reads over several slave machines. > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > User entries 1001-2000 live on DB2 and so on. It seems to me this isn't beyond doing in the current setup; but I'm not sure I understand the underlying mechanism well enough. For case 1, you need an object class that creates two (or more) (apparently identical) Models.model classes, one attached to each database, based on the field types declared as class variables: * on searches, it picks one of the model classes to search * on saves, saves the same data to each object class in turn For case 2, it's very similar, except you need to run the query on all sides (unless you can tell it should only go to one) building a chained query-set union type to hold the result, and for saves pick the right model to save to based on the condition. In each case, the underlying models have to be tied to the right databases, but this can be done using the mechanism in the proposal so far.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: user-friendly API for multi-database support
> obj = Article.objects.using('master').get(pk = 4)
> obj.name = 'Hello'
> obj.save(using = 'master')
Shouldn't the object remember the database used to fetch it, and
save()
should save it back there?Then you would only have to specify it
like that if you want to fetch it from one database and save it in
another
explicitly...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: user-friendly API for multi-database support
On Sep 10, 12:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > For those who weren't at DjangoCon, here's the state of play with > regards to multi-db support: Django actually supports multiple > database connections right now: the Query class (in django/db/models/ > sql/query.py) accepts a connection argument to its constructor, and > the QuerySet class (django/db/models/query.py) can be passed an > optional Query instance - if you don't pass it one, it will create a > Query that uses the default django.db.connection. Hmm.. so to the first layer of the onion, that statement is true... But now, how does one get a custom connection? Altnernate connection info needs to be able to be passed in to the DatabaseWrapper constructors, so that you can call them with different database information; and then when BaseDatabaseWrapper.cursor() calls _cursor() it should pass in a *copy* of the global settings overridden with anything passed in as kwargs to BaseDatabaseWrapper.__init__() (which is already saved in self.options) . That is, instead of def cursor(self): from django.conf import settings cursor = self._cursor(settings) if settings.DEBUG: return self.make_debug_cursor(cursor) return cursor We should do: def cursor(self): from django.conf import settings mysettings = settings.copy().update(self.options) cursor = self._cursor(mysettings) if settings.DEBUG: return self.make_debug_cursor(cursor) return cursor And then we can do something like from django.db.backends.mysql.base import DatabaseWrapper as OracleDatabaseWrapper myconnection = OracleDatabaseWrapper(DATABASE_HOST='somwhere.example.com', DATABASE_USER='tiger', ... ) and then you could use myconnection in your Manager subclass, etc. Anyhow, that seems to me like it is a stab at addressing the simple "some model classes talk to a different database" approach. One could make a ManagerWithAlternateConnection class that is a subclass of Manager and takes a database connection as a parameter and does that. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: I want a pony: Django Cheeseshop
On Sep 16, 2:16 am, mrts <[EMAIL PROTECTED]> wrote: > * generally we should strive for a hassle-free experience so that > `easy_install django-foo` gives you an expected entry point (`from > django.apps import foo`) and works-out-of-the-box feel Just a slightly twisted thought, what if a site's manage.py had a 'python manage.py easy_install foo' that would install the foo application in the current site directory, and automagically add a sample urls.py entry for it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
