Query abouhe multiple database support using mongoDB
Dear all I have a requirement to integrate the multiple database using mongodb is this possible to integrate the multiple database with mongodb and if possible then whats the process involved in this process Regards Shvam Taneja -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1dd51963-f5a7-4f7c-b299-9b492338e3d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Multiple Database Support
Hi Lee, There's been a lot of historic discussion about multi-database support, and the upshot is that no it isn't supported well right now. There's a branch in SVN, but it's pretty much defunct. I believe the current thinking is to use SQLAlchemy if you need to access other databases (try looking at the tranquil project on google code for some django-SA integration stuff). Cheers, Ben On 02/03/2008, Lee Connell <[EMAIL PROTECTED]> wrote: > > > Hello, > > I seen some code in trak for multiple db support. Is this something > that is usable now, is there some documentation on it? I have my app > that mainly interacts with mysql but I need to pull some data from a > mssql database for specific reasons, is this possible or should i just > use ado-mssql or pyodbc by itself? > > > -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Multiple Database Support
Hello, I seen some code in trak for multiple db support. Is this something that is usable now, is there some documentation on it? I have my app that mainly interacts with mysql but I need to pull some data from a mssql database for specific reasons, is this possible or should i just use ado-mssql or pyodbc by itself? --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Support
I thought this *was* the last one that was asked :) On Nov 7, 4:01 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Nov 8, 2007 7:00 AM, Josh <[EMAIL PROTECTED]> wrote: > > > > > Hi! > > > Has there been any more progress toward getting themultipledatabase > > branch merged into trunk? I, among many others, would really like to > > be able to use the newer features of django and accessmultiple > > databases from the same project... > > Search the archives for the last time this question was asked. The > answer hasn't changed. > > 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Support
Hi! Has there been any more progress toward getting the multiple database branch merged into trunk? I, among many others, would really like to be able to use the newer features of django and access multiple databases from the same project... Thanks! Josh On Oct 17, 12:03 am, koenb <[EMAIL PROTECTED]> wrote: > Hi Mark, > > You can find some newer work at ticket #4747. The patches there are > some work in progress trying to bring multi-db back in line with > trunk. > A lot has changed in trunk in the last year, so I think it is worth > trying those out instead of the old branch. Off course there are still > a lot of improvements to be made, but it is a start. > > Koen > > On 17 okt, 02:23, markg <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I need to supportmultipledatabaseconnections in our Django > > application. > > One option being considered is to use the multi-db branch > > athttp://code.djangoproject.com/svn/django/branches/multiple-db-support > > which is already in alpha release. > > > However by examining the code, it seems the development on this branch > > has stalled. Does anyone know the state of this branch and the release > > plan? Is there any other option available? > > > Thanks a lot, > > mark --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
Hi There, I've had similar problems and it comes down to the line in query.py that looks in backend and sets QuerySet to _QuerySet or backend.QuesrySet if there is one... I've also written some code to mitigate against this, and I'd suggest anyone with an interest gets together on this so that we're not all running round fixing the same problems! Perhaps it's time to update the multi-db wiki page to get some ideas together on how we can move forward with the branch, especially given recent changes in backend and forthcoming ones in QuerySet stuff. I've been mega busy lately and haven't had time to write anything up, I also don't have internet at home at the moment so even emailing might be a bit intermittent! What do you all think? Ben On 18/10/2007, Carlos Hanson <[EMAIL PROTECTED]> wrote: > > > On Oct 17, 1:29 pm, Carlos Hanson <[EMAIL PROTECTED]> wrote: > > On Oct 17, 12:33 am, koenb <[EMAIL PROTECTED]> wrote: > > > > > In the latest patches for multi-db the QuerySet that is returned is no > > > longer fixed, but varies with the model's manager. That should fix > > > that problem for now. > > > > > Koen > > > > I've installed the latest patches for multi-db agains revision 6453. > > It had the same problem. Then I removed the import connection and > > replaced it as suggested and got the following: > > > > Traceback (most recent call last): > > File "", line 1, in ? > > File "/usr/local/lib64/python2.4/site-packages/django/db/models/ > > manager.py", line 65, in all > > return self.get_query_set() > > File "/usr/local/lib64/python2.4/site-packages/django/db/models/ > > manager.py", line 56, in get_query_set > > QS = self.db.connection.ops.query_set_class(_QuerySet) > > File "/usr/local/lib64/python2.4/site-packages/django/db/backends/ > > oracle/base.py", line 96, in query_set_class > > connection = self.model._default_manager.db.connection > > AttributeError: 'DatabaseOperations' object has no attribute 'model' > > > > > On 17 okt, 09:03, Ian <[EMAIL PROTECTED]> wrote: > > > > > > I don't know anything about the multi-db branch, but I imagine that > > > > whatever QuerySet does to get the correct connection should work in > > > > OracleQuerySet as well. > > > > > > Note the mere existence of OracleQuerySet will still be problematic > in > > > > multi-db environments that mix Oracle databases with non-Oracle > > > > databases, since OracleQuerySet replaces QuerySet entirely when > Oracle > > > > is used. However, OracleQuerySet is a hack that will be going away > > > > after the QuerySet refactor, which solves both problems in the long > > > > run. > > > > > > Ian > > > > I will take a look at what QuerySet does to get the connection and see > > how it differs from OracleQuerySet. > > > > Thanks. If you have anything else, I appreciate it. If I happen to > > solve the problem, you'll see it here. > > > > Carlos > > I put the following line in the wrong place: > > connection = self.model._default_manager.db.connection > > It needs to go in two places in the OracleQuerySet: first, in the > iterator() method; second, in the _get_sql_clause() method. The > original import made connection a global name, and the reference to > self.model is not valid at that point. It must be in the > OracleQuerySet methods. > > Thanks for the help. > > Carlos > > > > > -- Regards, Ben Ford [EMAIL PROTECTED] +6281317958862 --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Support
Thanks Koen! I will try the patch. On Oct 17, 12:03 am, koenb <[EMAIL PROTECTED]> wrote: > Hi Mark, > > You can find some newer work at ticket #4747. The patches there are > some work in progress trying to bring multi-db back in line with > trunk. > A lot has changed in trunk in the last year, so I think it is worth > trying those out instead of the old branch. Off course there are still > a lot of improvements to be made, but it is a start. > > Koen > > On 17 okt, 02:23, markg <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I need to support multiple database connections in our Django > > application. > > One option being considered is to use the multi-db branch > > athttp://code.djangoproject.com/svn/django/branches/multiple-db-support > > which is already in alpha release. > > > However by examining the code, it seems the development on this branch > > has stalled. Does anyone know the state of this branch and the release > > plan? Is there any other option available? > > > Thanks a lot, > > mark --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
On Oct 17, 1:29 pm, Carlos Hanson <[EMAIL PROTECTED]> wrote: > On Oct 17, 12:33 am, koenb <[EMAIL PROTECTED]> wrote: > > > In the latest patches for multi-db the QuerySet that is returned is no > > longer fixed, but varies with the model's manager. That should fix > > that problem for now. > > > Koen > > I've installed the latest patches for multi-db agains revision 6453. > It had the same problem. Then I removed the import connection and > replaced it as suggested and got the following: > > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib64/python2.4/site-packages/django/db/models/ > manager.py", line 65, in all > return self.get_query_set() > File "/usr/local/lib64/python2.4/site-packages/django/db/models/ > manager.py", line 56, in get_query_set > QS = self.db.connection.ops.query_set_class(_QuerySet) > File "/usr/local/lib64/python2.4/site-packages/django/db/backends/ > oracle/base.py", line 96, in query_set_class > connection = self.model._default_manager.db.connection > AttributeError: 'DatabaseOperations' object has no attribute 'model' > > > On 17 okt, 09:03, Ian <[EMAIL PROTECTED]> wrote: > > > > I don't know anything about the multi-db branch, but I imagine that > > > whatever QuerySet does to get the correct connection should work in > > > OracleQuerySet as well. > > > > Note the mere existence of OracleQuerySet will still be problematic in > > > multi-db environments that mix Oracle databases with non-Oracle > > > databases, since OracleQuerySet replaces QuerySet entirely when Oracle > > > is used. However, OracleQuerySet is a hack that will be going away > > > after the QuerySet refactor, which solves both problems in the long > > > run. > > > > Ian > > I will take a look at what QuerySet does to get the connection and see > how it differs from OracleQuerySet. > > Thanks. If you have anything else, I appreciate it. If I happen to > solve the problem, you'll see it here. > > Carlos I put the following line in the wrong place: connection = self.model._default_manager.db.connection It needs to go in two places in the OracleQuerySet: first, in the iterator() method; second, in the _get_sql_clause() method. The original import made connection a global name, and the reference to self.model is not valid at that point. It must be in the OracleQuerySet methods. Thanks for the help. Carlos --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
On Oct 17, 12:33 am, koenb <[EMAIL PROTECTED]> wrote: > In the latest patches for multi-db the QuerySet that is returned is no > longer fixed, but varies with the model's manager. That should fix > that problem for now. > > Koen I've installed the latest patches for multi-db agains revision 6453. It had the same problem. Then I removed the import connection and replaced it as suggested and got the following: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib64/python2.4/site-packages/django/db/models/ manager.py", line 65, in all return self.get_query_set() File "/usr/local/lib64/python2.4/site-packages/django/db/models/ manager.py", line 56, in get_query_set QS = self.db.connection.ops.query_set_class(_QuerySet) File "/usr/local/lib64/python2.4/site-packages/django/db/backends/ oracle/base.py", line 96, in query_set_class connection = self.model._default_manager.db.connection AttributeError: 'DatabaseOperations' object has no attribute 'model' > On 17 okt, 09:03, Ian <[EMAIL PROTECTED]> wrote: > > > I don't know anything about the multi-db branch, but I imagine that > > whatever QuerySet does to get the correct connection should work in > > OracleQuerySet as well. > > > Note the mere existence of OracleQuerySet will still be problematic in > > multi-db environments that mix Oracle databases with non-Oracle > > databases, since OracleQuerySet replaces QuerySet entirely when Oracle > > is used. However, OracleQuerySet is a hack that will be going away > > after the QuerySet refactor, which solves both problems in the long > > run. > > > Ian I will take a look at what QuerySet does to get the connection and see how it differs from OracleQuerySet. Thanks. If you have anything else, I appreciate it. If I happen to solve the problem, you'll see it here. Carlos --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
In the latest patches for multi-db the QuerySet that is returned is no longer fixed, but varies with the model's manager. That should fix that problem for now. Koen On 17 okt, 09:03, Ian <[EMAIL PROTECTED]> wrote: > I don't know anything about the multi-db branch, but I imagine that > whatever QuerySet does to get the correct connection should work in > OracleQuerySet as well. > > Note the mere existence of OracleQuerySet will still be problematic in > multi-db environments that mix Oracle databases with non-Oracle > databases, since OracleQuerySet replaces QuerySet entirely when Oracle > is used. However, OracleQuerySet is a hack that will be going away > after the QuerySet refactor, which solves both problems in the long > run. > > Ian --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Support
Hi Mark, You can find some newer work at ticket #4747. The patches there are some work in progress trying to bring multi-db back in line with trunk. A lot has changed in trunk in the last year, so I think it is worth trying those out instead of the old branch. Off course there are still a lot of improvements to be made, but it is a start. Koen On 17 okt, 02:23, markg <[EMAIL PROTECTED]> wrote: > Hi, > > I need to support multiple database connections in our Django > application. > One option being considered is to use the multi-db branch > athttp://code.djangoproject.com/svn/django/branches/multiple-db-support > which is already in alpha release. > > However by examining the code, it seems the development on this branch > has stalled. Does anyone know the state of this branch and the release > plan? Is there any other option available? > > Thanks a lot, > mark --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
On Oct 16, 6:38 pm, Carlos Hanson <[EMAIL PROTECTED]> wrote:
> I am having trouble with Django revision 6110 patched with multi-
> db-6110.patch.
>
> Traceback (most recent call last):
> File "", line 1, in ?
> File "/usr/local/lib64/python2.4/site-packages/django/db/models/
> query.py", line 108, in __repr__
> return repr(self._get_data())
> File "/usr/local/lib64/python2.4/site-packages/django/db/models/
> query.py", line 484, in _get_data
> self._result_cache = list(self.iterator())
> File "/usr/local/lib64/python2.4/site-packages/django/db/backends/
> oracle/base.py", line 119, in iterator
> cursor.execute(full_query, params)
> File "/usr/local/lib64/python2.4/site-packages/django/db/backends/
> util.py", line 19, in execute
> return self.cursor.execute(sql, params)
> ProgrammingError: relation "ttsd_schools" does not exist
>
> The problem seems to be in django/db/backends/oracle/base.py on line
> 92:
>
> from django.db import connection
>
> which is later used to get the cursor. This seems to bypass the use
> of the database settings in OTHER_DATABASES. I would expect to use
> connections from django.db rather than connection:
>
> # Create a manager for named connections
> connections = LazyConnectionManager()
>
> # Backwards compatibility: establish the default connection and set
> the
> # default connection properties at module level, using the lazy
> proxy so that
> # each thread may have a different default connection, if so
> configured
> connection_info = LocalizingProxy('connection_info', _local,
> lambda: connections[_default])
> connection = LocalizingProxy('connection', _local,
>lambda:
> connections[_default].connection)
>
> But I don't see how to get the named connection in oracle/base.py.
>
> If that is clear, I would appreciate any suggestions.
>
> Carlos Hanson
I don't know anything about the multi-db branch, but I imagine that
whatever QuerySet does to get the correct connection should work in
OracleQuerySet as well.
Note the mere existence of OracleQuerySet will still be problematic in
multi-db environments that mix Oracle databases with non-Oracle
databases, since OracleQuerySet replaces QuerySet entirely when Oracle
is used. However, OracleQuerySet is a hack that will be going away
after the QuerySet refactor, which solves both problems in the long
run.
Ian
--~--~-~--~~~---~--~~
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@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-users?hl=en
-~--~~~~--~~--~--~---
Re: multiple database support: oracle backend
Sorry Carlos,
those patches are far from complete, and I don't use Oracle myself.
For the moment the backends in the patches use the following to get
the connection:
connection = self.model._default_manager.db.connection
Removing the import and putting in that line should do the trick.
There is plenty more wrong (certainly with that 6110 patch, the 6453
one is a little better), but I haven't had the time to work on it
further.
Koen
> The problem seems to be in django/db/backends/oracle/base.py on line
> 92:
>
> from django.db import connection
>
> which is later used to get the cursor. This seems to bypass the use
> of the database settings in OTHER_DATABASES. I would expect to use
> connections from django.db rather than connection:
>
> # Create a manager for named connections
> connections = LazyConnectionManager()
>
> # Backwards compatibility: establish the default connection and set
> the
> # default connection properties at module level, using the lazy
> proxy so that
> # each thread may have a different default connection, if so
> configured
> connection_info = LocalizingProxy('connection_info', _local,
> lambda: connections[_default])
> connection = LocalizingProxy('connection', _local,
>lambda:
> connections[_default].connection)
>
> But I don't see how to get the named connection in oracle/base.py.
>
> If that is clear, I would appreciate any suggestions.
>
> Carlos Hanson
--~--~-~--~~~---~--~~
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@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-users?hl=en
-~--~~~~--~~--~--~---
multiple database support: oracle backend
I am having trouble with Django revision 6110 patched with multi-
db-6110.patch.
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib64/python2.4/site-packages/django/db/models/
query.py", line 108, in __repr__
return repr(self._get_data())
File "/usr/local/lib64/python2.4/site-packages/django/db/models/
query.py", line 484, in _get_data
self._result_cache = list(self.iterator())
File "/usr/local/lib64/python2.4/site-packages/django/db/backends/
oracle/base.py", line 119, in iterator
cursor.execute(full_query, params)
File "/usr/local/lib64/python2.4/site-packages/django/db/backends/
util.py", line 19, in execute
return self.cursor.execute(sql, params)
ProgrammingError: relation "ttsd_schools" does not exist
The problem seems to be in django/db/backends/oracle/base.py on line
92:
from django.db import connection
which is later used to get the cursor. This seems to bypass the use
of the database settings in OTHER_DATABASES. I would expect to use
connections from django.db rather than connection:
# Create a manager for named connections
connections = LazyConnectionManager()
# Backwards compatibility: establish the default connection and set
the
# default connection properties at module level, using the lazy
proxy so that
# each thread may have a different default connection, if so
configured
connection_info = LocalizingProxy('connection_info', _local,
lambda: connections[_default])
connection = LocalizingProxy('connection', _local,
lambda:
connections[_default].connection)
But I don't see how to get the named connection in oracle/base.py.
If that is clear, I would appreciate any suggestions.
Carlos Hanson
--~--~-~--~~~---~--~~
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@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-users?hl=en
-~--~~~~--~~--~--~---
Multiple Database Support
Hi, I need to support multiple database connections in our Django application. One option being considered is to use the multi-db branch at http://code.djangoproject.com/svn/django/branches/multiple-db-support which is already in alpha release. However by examining the code, it seems the development on this branch has stalled. Does anyone know the state of this branch and the release plan? Is there any other option available? Thanks a lot, mark --~--~-~--~~~---~--~~ 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@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django and Multiple Database Support
On 1/10/06, Greg <[EMAIL PROTECTED]> wrote: > So I hacked > DatabaseWrapper.quote_name so that it doesn't quote periods, but is > that the "right" way to handle this or is it an ugly hack? It seems to > work very well, but it feels like it might be cleaner to add a > db_schema attribute or something instead. (Should I submit a patch? :-) Perhaps we could have the best of both worlds, and have the Model constructor split on period, storing db_schema internally if a schema was provided. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: Django and Multiple Database Support
I'm faced with the multiple-schema problem in MySQL, which AFAICT is a lot simpler than actually having multiple databases because at least you don't have to coordinate multiple connections. Actually, it basically already works. I wrote class Poll(meta.Model): class META: db_table = "myschema.poll" but then Django tries to quote the whole name (including the period) which of course makes MySQL complain (beause the SQL should be `myschema`.`poll`, not `myschema.poll`). So I hacked DatabaseWrapper.quote_name so that it doesn't quote periods, but is that the "right" way to handle this or is it an ugly hack? It seems to work very well, but it feels like it might be cleaner to add a db_schema attribute or something instead. (Should I submit a patch? :-)
Re: Django and Multiple Database Support
On Friday 30 Dec 2005 5:12 am, hugo wrote: > So, yes, I do think it would be very useful for Django to be able > to access multiple databases via it's ORM incidently, we need support for postgres schemas also - i have an Financial Accounting app where, in multi-company mode, the tables for each company are stored in a separate schema, also for multilingual stuff this is ideal -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Re: Django and Multiple Database Support
>I've always though that this particular -- and common -- use case >should be delegated to the DB level using one of the many excellent >replication/distribution tools for your database. For example, you >could easily do read distribution with pg_pool or sqlrelay, and it >would be transparent to Django. I don't see a good reason to tackle >replication in Django itself as that's more or less a solved problem. Beside the fact that most of those "excellent" after-market replication solutions just plain suck ;-) - there are very good reasons to have data-driven distribution. This might be controlled by tables - some tables living on different databases or servers - or by content. Like data from older years living in other databases or on other servers. So even if you get those replication solutions to work reliable (which I never was able to do with sqlrelay - the client goes bozo if the server has problems), you _can't_ do those data-driven distribution with after-market tools. This has to be done on application level. A scenario from my work: a ERP system which produces loads of accounting data. Older data is moved to some external database, because it would put too much load on the active database. Then there are special data aggregates that are stored in another database for faster queries - they are specially prepared. So the application needs to access three databases simultaniously. And in large installations, those databases will be even run on different servers. So, yes, I do think it would be very useful for Django to be able to access multiple databases via it's ORM. Actually I have already exactly that requirement in some Django project: while trying to build a admin interface for my db-based nameserver and db-based mail-system, I have the problem that DNS and Mail are handled by different databases, so I am blocked on that project currently, as Django won't let me work with both databases ... bye, Georg
Re: Django and Multiple Database Support
On 29 Dec 2005, at 20:29, Jacob Kaplan-Moss wrote: I've always though that this particular -- and common -- use case should be delegated to the DB level using one of the many excellent replication/distribution tools for your database. For example, you could easily do read distribution with pg_pool or sqlrelay, and it would be transparent to Django. I don't see a good reason to tackle replication in Django itself as that's more or less a solved problem. I disagree. There's a lot more to separate databases than just replication - when you scale big there are all kinds of ways things might need to be partitioned. You might want to keep "cheap" data (like traffic logs for user's weblogs) on a different DB cluster from expensive data (like their blog entries themselves). Some data gets accessed all the time while some other data is only ever written - etc etc. I'd love Django to have a reputation as the web framework that scales. As far as I can tell, big LAMP sites that scale are mostly done as PHP with a whole load of custom scary stuff - connections to multiple databases, memcached, even XMLRPC calls to backend services written in Java. We already have caching and we can do calls to backend services easily but the single database connection assumption is baked right in to the framework. Unfortunately, I don't have the experience of scaling big to say much more than that. This is where input from people like Scott becomes invaluable :) Cheers, Simon
Re: Django and Multiple Database Support
On Dec 29, 2005, at 9:10 AM, Adrian Holovaty wrote: ... or would you be doing more of a standard setup, in which you'd want database reads to be spread evenly across multiple DBs? Go ahead and explain the setup, and we can get started on designing the feature. I've always though that this particular -- and common -- use case should be delegated to the DB level using one of the many excellent replication/distribution tools for your database. For example, you could easily do read distribution with pg_pool or sqlrelay, and it would be transparent to Django. I don't see a good reason to tackle replication in Django itself as that's more or less a solved problem. Jacob
Re: Django and Multiple Database Support
On 12/29/05, Scott johnson <[EMAIL PROTECTED]> wrote: > Now I haven't hacked Django much myself yet (I've been working on the back > end tools, db loader and overall schema). What support does Django have for > multiple db stuff? Hey Scott, Welcome! Django doesn't support multiple DBs out of the box, but this is something we (Simon particularly) have been very keen on adding. Fortunately, the database code is rather nicely abstracted, so most of the refactoring would be in just two modules. To what extent would you be using multiple DBs? Would you be employing the technique whereby certain records (e.g. users 1 to 1,000,000) are in certain databases, or would you be doing more of a standard setup, in which you'd want database reads to be spread evenly across multiple DBs? Go ahead and explain the setup, and we can get started on designing the feature. > Also we'll need to write a baseline simple > db backed, captcha class near immediately to keep out the spam bots. Any > interest in our contributing that back? Sure, we're always interested in contributions! You might have a look at Ian Holsman's Django captcha app here: http://feh.holsman.net/articles/2005/12/15/django-captcha-app I haven't looked at the code myself, but it could be helpful. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Django and Multiple Database Support
Hello, *Long time lurker; first time poster*. My partner and I are standarizing on Django / Python for the front end of www.ookles.com, our new startup. We're both php folk and I've convinced him that Django is better than ruby (based, honestly, on my respect for Simon and Adrian rather than a real analysis; transitive geek fu; any who). The issue at hand for us is we have essentially one application: Ookles which is a highly interactive web site. Now having scaled a MySQL app (lets not go down the postgres discussion; we're using MySQL 5 so we have views and stored procs) to the terabyte level at my last gig, I learned the lesson of "DO NOT; REPEAT DO NOT; PUT EVERYTHING IN ONE DB". But it at least feels like Django is really oriented around the concept of one db. To wit: I've been playing with django today (really like it so far!). To start a project, you define your database model with a set of sub-classes representing each database table. Once you've defined everything you can do a couple of things, either " django-admin.py sql app" which will spit out an sql script for you to create your database tables with or you can do "django-admin.py install app" and that will create all the tables for you. Fantastic stuff and if you can get your head around doing it this way, then it saves time by having the model setup and the database. So far, Django feels much more solid than rails. Yes, you have to do more but you feel good about doing it. Relying on rails magic is sometimes a little hard to swallow :)(From my co founder Mike)Now I haven't hacked Django much myself yet (I've been working on the back end tools, db loader and overall schema). What support does Django have for multiple db stuff? I apologize if this is a real newbie question. I did run through the basic docs (great job btw; thank you). Also we'll need to write a baseline simple db backed, captcha class near immediately to keep out the spam bots. Any interest in our contributing that back? ThanksScott-- ---J. Scott Johnson *** Now Available for Consulting ***blog: http://fuzzyblog.com/ [EMAIL PROTECTED]aim: fuzzygroupcell: 857 222 6459---
