osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: 1.2 alpha, multiple databases, and raw SQL -
msg#01419

List: django-users

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

On Thu, Jan 28, 2010 at 10:41 AM, Chris Curvey <ccurvey@xxxxxxxxx> wrote:
> Is there a way to use raw SQL with multiple databases?  I thought it
> might be something like:
>
> from django.db import connection
> cursor = connection.cursor(using="mydb")
>
> but that complains about an unexpected keyword arg.

It is possible, but not like that.

There are a couple of ways to handle raw SQL over multiple databases,
depending on exactly what you want to do.

If you want to do a SELECT on a specific model, but with some
eccentric FROM/WHERE/HAVING clause that Django doesn't support, you
can use the new raw query method:

Author.objects.raw('SELECT id, name FROM library_authors WHERE ....')

To make this a query on a different database:

Author.objects.db_manager('mydb').raw('SELECT id, name FROM
library_authors WHERE ....')

The db_manager() clause gives you a version of the objects manager
that has been forced to use the 'mydb' database. Every manager
provides a raw() method that allows you to call raw sql, and return
model objects. So - this query will run your raw SQL on the mydb
database.

If you have a database router installed, you may not need the
db_manager() query. The raw() query will interrogate the master router
to find the appropriate read database; if your router is set up to
direct 'Author' read queries to 'mydb', the original
Author.objects.raw() query will operate on the mydb database
automagically.

If you want to do an UPDATE, INSERT, or some other SQL query, you need
to fall back to using a cursor as before. To access a multi-db cursor,
we haven't changed the connection interface - we've changed the way
you get a connection.

from django.db import connections

cursor = connections['mydb'].cursor()
cursor.execute('INSERT ....')

That is, the 'db.connection' object has been replaced with an index
called 'db.connections', keyed by database alias. Each of those
connections behaves as the single connection did in 1.1.

The old 'db.connection' object has been retained for backwards
compatibility, but it is assumed to be no more than an alias for:

connections['default']

I hope that clarifies things.

Yours,
Russ Magee %-)

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

Thread at a glance:

Previous Message by Date:

1.2 alpha, multiple databases, and raw SQL

Is there a way to use raw SQL with multiple databases? I thought it might be something like: from django.db import connection cursor = connection.cursor(using="mydb") but that complains about an unexpected keyword arg. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to django-users+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Next Message by Date:

Re: URL design - why the trailing slash?

Hi, On Thu, Jan 28, 2010 at 8:54 AM, Brett Thomas <brettpthomas@xxxxxxxxx> wrote: > Most of the URLConf examples I run across use a trailing slash on all URLs: > www.example.com/profile/ > > I'm not sure why, but I don't like this. I think it looks nicer without: > www.example.com/profile I believe that it is just a matter of personal preference: some people like to always have a slash appended (or never appended) for consistency. I prefer to append a slash when the page is some kind of category, but leave it out when it is a "leaf node". (I noticed that this is what the W3C website does.) > Are there any performance or security reasons to use the trailing slash in > Django? Seems like there could be some quirk with regular expressions that > I'm not thinking of... I do not know about performance, but I doubt there is a security issue, otherwise it would not have made sense to make the APPEND_SLASH setting behave the way it does, i.e., a slash is not appended if the initial URL (without a trailing slash) can be found in the URLconf. Regards, Eugene Wee -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to django-users+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Previous Message by Thread:

1.2 alpha, multiple databases, and raw SQL

Is there a way to use raw SQL with multiple databases? I thought it might be something like: from django.db import connection cursor = connection.cursor(using="mydb") but that complains about an unexpected keyword arg. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to django-users+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Next Message by Thread:

Re: 1.2 alpha, multiple databases, and raw SQL

> > from django.db import connections > > cursor = connections['mydb'].cursor() > cursor.execute('INSERT ....') > > That is, the 'db.connection' object has been replaced with an index > called 'db.connections', keyed by database alias. Each of those > connections behaves as the single connection did in 1.1. > > The old 'db.connection' object has been retained for backwards > compatibility, but it is assumed to be no more than an alias for: > > connections['default'] > > I hope that clarifies things. > > Yours, > Russ Magee %-) Perfect! thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@xxxxxxxxxxxxxxxxx To unsubscribe from this group, send email to django-users+unsubscribe@xxxxxxxxxxxxxxxxx For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!