What you are talking about here is somewhat covered in
http://code.djangoproject.com/ticket/6148
But here it is called db_schema instead.
In mysql "schema" is aliased to database. In postgres, (and probably
oracle) it actually is a different schema within the same database.
I made some work on
Hello all,
I just wanted to toss in my own $0.02 for my particular use case and
my experiences thus far. For all around ease, this is a copy of a
comment I made on ticket #1142 yesterday:
What is the current status on this issue? There doesn't appear to have
been any visible movement in
Oops looks like I got distracted and hit send mid-thought. That last
part is supposed to be:
Obviously this function could get very complicated for a heavily
sharded setup, but sharding is complicated by definition, so where
that complexity goes isn't necessarily relevant. Letting this logic
So, I'm still learning my way around the deeper parts of the codebase,
but at first glance the "function pointed to from settings.py"
approach seems best. This way, the connection management is completely
opaque to the model. If that function isn't defined, it can just fall
back to the default
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
Simon, that's great! I think I can overlook the hackiness in my
excitement. I am in your debt.
On Sep 12, 5:18 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 12, 7:45 pm, Brent Hagany <[EMAIL PROTECTED]> wrote:
>
> > As far as I can tell, the argument about being portable is a good
On Sep 12, 7:45 pm, Brent Hagany <[EMAIL PROTECTED]> wrote:
> As far as I can tell, the argument about being portable is a good one,
> and if that ends up being the reason this doesn't get in right away,
> then I can't complain. However, the part about the single server
> making this more
On Sep 12, 10:46 pm, TP <[EMAIL PROTECTED]> wrote:
> > This means an ORM object should have a
> > special property on it recording which database connection it was
> > loaded from. It also presumes we won't ever want to support the case
>
> I apologize for my ignorance as to how django DB
On Fri, 2008-09-12 at 14:46 -0700, TP wrote:
[...]
> Also, what if the connection has closed for whatever reason since the
> object was loaded (due to DB connection timeout, DB restart, etc)?
The django.db.connection object isn't a pure network connection. It's a
DatabaseWrapper class and knows
Simon Willison wrote:
> That sounds smart to me. There are cases where you want to select from
> one database and then save to another (moving data between different
> database servers, re-sharding data for whatever reason) but the common
> case will be as you describe. This means an ORM object
Now I'm nobody special, and I probably don't even belong in this
group, but I do want to voice my support for this part of the original
proposal:
> Dealing with single queries that span multiple databases
>
> Once you have different
On Sep 12, 5:11 pm, mengel <[EMAIL PROTECTED]> wrote:
> > 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
> 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
On Wed, 2008-09-10 at 13:16 -0700, koenb wrote:
[...]
> As far as I can tell, this is not supported currently by the plumbing
> Malcolm provided (since the operations settings eg in WhereNode are
> taken from the default connection and not from the passed in
> connection; this is no problem if
FWIW as a possible data point, our team has implemented partitioned
models in Oracle. To control this I added a settings parameter with a
list or models to be partitioned. The actual work is done in the
sqlreset command logic (but really needs to be in the table/index
generation code for SQL
On Sep 10, 2:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
> For application-wide db connections, I think it'd be much easier and
> more portable to choose the connection in settings.py rather than in a
> Model.
>
I agree with you Justin. The applications should remain db
agnostic.
We
On Sep 10, 7:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> Dealing with single queries that span multiple databases
>
>
> Once you have different tables living in different databases there's
> always the chance that someone will try to
I just wanted to toss out one more use case that I know I would find
especially useful. Legacy databases.
I'd like to see the ability to setup a model (using rough
introspection and then user tweaking) based on a legacy database,
maybe with the options of read-write or read-only access.
Like
Wow, i'm with Malcolm on the "steady on, let's take this a bit at a
time" :) Someone has been working hard, but that's a huge amount to
think about.
Reading through some of the comments: Most of the functionality
described here would be an explicit mapping and choice made by the
developer, it
ab wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive. I also propose that you can either
> define a
On Sep 10, 10:55 pm, ab <[EMAIL PROTECTED]> wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive.
I'm
On Wed, 2008-09-10 at 15:03 -0700, Mike Malone wrote:
[...]
> I think it just needs refining. My understanding is that related
> fields was due for a refactor anyways, so this would probably be a
> good time to do / think about it. I guess my point is that there needs
> to be some non-internal
On Sep 10, 10:44 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
It's redundant in the case of a single master, but there are other
> On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> > At Pownce, for example, we stick users to the master database for some
> > period of time (a couple of seconds, usually) after they post a new note.
> > The problem here (as Malcolm pointed out) is that related managers use
> the
For the api to accept a DSN, alias, or connection anywhere would add
similar code in multiple places. I propose that the aliases are mapped
into django.db.connections. For your example, you could use
django.db.connections.archive. I also propose that you can either
define a single database (as
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
>
Not so. There are certainly use-cases for more sophisticated database
architectures where, for example, the majority of the
Simon Willison wrote:
> That's really interesting. I wonder if that invalidates the whole
> approach I proposed, or merely means it needs some refining?
As Malcolm has pointed you're proposing many things at once :-). I tend
to think that replication, sharding, migration to another db are very
Simon Willison wrote:
> Good point. That also highlights an omission in my original brain-dump
> - having a "uses" method on a QuerySet isn't enough, you also need a
> way of over-riding the database connection used by a call to
> model.save(). Again, I'd propose the same terminology again as a
>
On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new note.
> The problem here (as Malcolm pointed out) is that related managers use the
> default
Mike Malone wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new
> note.
Another approach that I took in mysql_replicated[1] is to serve a page
that user GETs from a redirect after successful POST
On Sep 10, 10:15 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > * Simple master-slave replication: SELECT queries are distributed
> > between slaves, while UPDATE and DELETE statements are sent to
> > the master.
>
> It won't work on a statement-level. If you have a
Wow... like Malcom said, lots to digest here.
So to start, the "simple" master-slave replication scenario turns out not to
be so simple once you get into the implementation details. Replication lag
being what it is, you almost never way to query the slave for every SELECT.
At Pownce, for
Simon Willison wrote:
> * Simple master-slave replication: SELECT queries are distributed
> between slaves, while UPDATE and DELETE statements are sent to
> the master.
It won't work on a statement-level. If you have a transaction and do an
UPDATE and then a SELECT then the latter won't see
On Wed, Sep 10, 2008 at 12:30 PM, Simon Willison
<[EMAIL PROTECTED]> wrote:
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>> Model.
On Wed, 2008-09-10 at 20:40 +0100, Dan Fairs wrote:
> > 2. Have a setting which lets you say "for model auth.User, use the
> > get_connection method defined over here". This is made inelegant by
> > the fact that settings shouldn't really contain references to actual
> > function definitions,
Just to add a little note: back in May I did some work on multidb,
some thoughts and some work can be found on http://trac.woe-beti.de/ ,
which Ben Ford set up for this.
I stopped because django was becoming too much of a moving target to
keep it in sync (and i did not have the time).
I would
On Wed, Sep 10, 2008 at 3:30 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>>
> 2. Have a setting which lets you say "for model auth.User, use the
> get_connection method defined over here". This is made inelegant by
> the fact that settings shouldn't really contain references to actual
> function definitions, which means we would probably need to us a
>
On Sep 10, 7:17 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Also, as a general thing here, did you go back and read the various
> discussions we had about API when the multi-db Summer of Code project
> was running? If not, that would be worth doing and incorporating, since
> we debated a
The default setting defines the application-wide db connection.
The Manager mechanism is for overriding the default connection.
Selecting the db via signals makes no sense to me, however a mapping
between apps and databases in settings is worth a moment of thought as
a possible supplement to the
Okay, there's lots to digest here, but a couple of things that need
clarification / addition here that I spotted on the first reading.
Also, as a general thing here, did you go back and read the various
discussions we had about API when the multi-db Summer of Code project
was running? If not,
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
42 matches
Mail list logo
