On 4/9/07, Merric Mercer <[EMAIL PROTECTED]> wrote: > The issue with Cluster is that it is designed to work synchronously. > This is fine when the all the DB is on a fast, local network but not > when the DB needs to be replicated to geographically different networks, > where latency becomes a major issue.
Wide distribution of the database seems to me to be a fairly unusual case (and if the DB is distributed in that fashion, why can't the web nodes also be distributed, with round-robin DNS or some similar setup, so that they can remain in proximity to a particular database/DB cluster and make use of it?), so I'm not sure it's within scope to have to build this into a general-purpose application framework; again, it seems like some sort of dedicated connection management sitting between the layers is the ideal solution. > Django already cares and knows about the DB it uses - so I not sure I > agree that this can be abstracted out of Django and I can see a bunch > of reasons why Django needs to know more about the DB for large scale > projects. We'll have to agree to disagree, I guess; personally, I think that the less the application layer has to know about the other layers, the better, and that the ideal is a single point of connection between them. For a database to punt on what is essentially a database-layer issue, and demand that client-access logic be rewritten to suit the database developers' unwillingness to deal with it, is a bit disappointing. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
