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 several months now, and this is something which would be very useful in a project I'm working on. I have a slightly different use case than the previously mentioned ones, however... and I'm sure it's not an entirely common one, but perhaps something to take into consideration.
The company I work for is sitting on a fairly large data warehouse for a number of clients. Each client has their own database, with a common schema, on one of two MS SQL 2k servers. In the near future, we will hopefully be moving some of these clients onto a PostgreSQL server (and in the distant future, it would be nice to move towards Greenplum; although that should be transparent with psycopg2, afaik). In addition, there is a separate database already running on the PostgreSQL server, which stores configuration parameters and which I am using for the Django system tables. On every page load, I need Django to connect to database 'A' on the PostgreSQL server for any Django specific operations, then connect to an arbitrary database on either of the MS SQL servers, depending on which of our clients' data is currently being viewed. From what I've seen so far in the discussion in this ticket and on MultipleDatabaseSupport, this doesn't sound like it would likely be a supported scenario, as the connection to be used is determined dynamically, rather than a static connection chosen per model. In my case, all models apply across all database connections. Now, I have made this work thus far with my own connection manager (http://dpaste.com/hold/84458/) but using it is somewhat kludgy and I'm sure it's far from a full implementation. I also had to apply a hack (http://code.google.com/p/django-pyodbc/issues/detail?id=18) to django-pyodbc and apply a pending patch (#6710) to Django in order to get it to work. Here is an example of why it in use: http://dpaste.com/hold/84465/ ---- Having read through the posts on this thread, it appears that this was actually (somewhat) one of the mentioned approaches. As mentioned in one posting, however, this violates DRY in many ways. In my case however, this may be a necessity, unless I find some way to determine the connection in a piece of middleware, then make that connection globally available (without overriding the 'system' django.db.connection object). Now, the above is all good and well, and this has been working fairly well for me thus far... but I just hit one big stumbling block today. In fact, it's pretty much a 50 ft. brick wall in my path. The problem is in the get_db_prep_value() function for some field types. Line 609 of django/db/models/fields/__init__.py is the case I am running into at the moment. It is specifically referring to django.db.connection, regardless of what connection may have been tossed around between Query objects. Now even in most multi-db cases, this wouldn't cause a problem, because it's just asking the db driver how to convert the data. In my case, however, django.db.connection is a psycopg2 connection, while I'm actually querying from a pyodbc connection. This tends to make Django fairly unhappy. In fact, this prompted one of the most confusing Python error messages I have seen to date: "TypeError: * wants int" Looking through this same fields file, it appears that there are a great many direct references to the global connection object, and I'm not entirely sure how to work around this at the moment, aside from perhaps passing the connection to the Field object. Any input, suggestions, criticism, etc are welcome. --Joey Wilhelm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
