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 tables living in different databases there's > always the chance that someone will try to write a query that attempts > to join tables that live on two different database servers. I don't > think we should address this problem at all (aside from maybe > attempting to throw a descriptive error message should it happen) - if > you're scaling across different servers you need to be aware of the > limitations of that approach. > That said, databases like MySQL actually do allow cross-database joins > provided both databases live on the same physical server. Is this > something we should support? I'd like to say "no" and assume that > people who need to do that will be happy rolling their own SQL using a > raw cursor, but maybe I'm wrong and it's actually a common use case. As a relatively small-time developer, it seems silly to me not to include this from the get-go. From my point of view, things like sharding and replication are things that I probably will never need, unless one of my little projects suddenly makes it big. And maybe I'm naive, but I don't think that most Django users will ever need those things either. So, to see this part of the proposal downgraded in importance because it's perceived not to be a common use case strikes me as odd. This is, after all, something that a vanilla MySQL installation supports out of the box (my experience with other dbs is admittedly slim), while sharding and replication take siginificantly more work to set up, and are useful in a much smaller subset of situations. For my part, I need/want support for cross-database joins on the same server for two reasons that seem like they ought to be common. The first and most important is that I want to use the Django ORM in situations where the data is already happily living in separate databases on the same server. Since it often makes sense to organize data into multiple databases on the same server, many people working with data that was not specifically meant for use with Django are going to run into a problem switching to Django for any projects that use that data. This, at least for me, presents a very large barrier to introducing Django into many business situations. Secondly, and I know that this is anal, shoving all your data for every app into a single database is simply ugly. Databases provide precious little support for namespacing as it is, and I'd prefer to use what they have. If I have 15 Django apps installed, I don't want to see 100 tables when I fire up mysql and do a SHOW TABLES;. I want those apps to be nicely compartmentalized in the db and in the code, and not differentiated only by bastardized_underscore_namespacing. As to Malcolm's response: > My gut feeling is that this isn't something to include initially as a > necessary goal, but it's also probably not too hard once the other 95% > is done. My reason for saying 'no' initially is we try to be as portable > as possible and that particular case is very specific. Also, the single > physical server constraint makes it even more specialised. If you need > separate databases for performance reasons, particularly, they're not > going to be on the same physical server. 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 specialized, and the part about performance are non sequiturs. The vast majority of web applications run with a single database server; I don't see how that can be called specialized. And, the reasons for wanting to do cross-database joins (from my POV) have nothing to do with performance, so I don't really understand why it's relevant to this part of the proposal. I understand that performance is the main driving force behind most of this multi-db work, but there are other reasons that us small fish are looking forward to a multi-db api. Again, I'm not really a Django developer, so I apologize for my intrusion. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
