Hi carole.zieler, I posted a reply to you earlier but don't see it here so I guess it went to the groups twilight zone. Anyway I was just saying I'm glad to hear you are having success with the current state of the multidb branch. I've used it as a proof of concept but am hesitant to run with it because I have already begun tying myself to some of the features in the post-0.95 code base. Thank you for offering to take the lead on this project. I'd be glad to help out with testing since I would be a regular consumer of this functionality.
I think the django dev's svn/inclusion policies are very reasonable. In the event the devs do not grant you access, I wonder how they would feel about having a branch maintained somewhere else. My pretentious guess is that they wouldn't have a problem with it as long as it was made abundantly clear that the branch in no way represented the work, opinions, philosophies, etc. of the core django devs. If that's the case, I'd be happy to help you set up and administer a branch in an alternative location. This would seem to be a win all around as us outliers get the functionality we need and the django devs don't have to worry about spending any cycles on a branch they perceive as risky. I am confident that as Django gains traction this functionality will be more requested. I can't imagine that I'm one of the only people out there who works with a data architect that doesn't want his data warehouse "cluttered" with framework metadata. Since he has 20+ years experience in his field, I tend to listen to what he says. There are often very logical and sound reasons for separating data based on categorization (user/customer, administrative, reference, transactional) and/or use case (write-only, read-only, replication, data mining). Cheers -Brian On May 2, 8:04 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I've just posted over in django-dev that I'm intersted in taking over > maintenance of this branch ... I'm not to skilled with subversion... > but I'm going to go ahead and give it a shot, and attempt over the > next two weeks ( out of town for a few days on vacation ) to merge the > changes to the trunk into this branch. > > Once I get what I think is a proper merge of the newest code... I'll > inquire about the next step of how to it committed ... wish me luck :) > > On May 2, 10:41 am, brutimus <[EMAIL PROTECTED]> wrote: > > > I've also seen a lot of demand for the multi-db support; however, I do > > understand the time that this would take to get updated, stabilized, > > and worked into trunk. I have several apps I would like to work on > > where I need to pull data from a couple legacy databases > > (datawarehouse type dbs), but this proves difficult. To this point, > > I've been a little hesitant to run the multi-db branch, but I may have > > to look at it and see how that works out. > > > If anyone who is capable puts time into getting the multi-db branch up > > to par and added into trunk, I know many people would be very > > thankful. > > > Thanks, Sean > > > On May 2, 12:22 am, Brian Luft <[EMAIL PROTECTED]> wrote: > > > > Hi Russ, > > > > Thanks for the detailed response and I agree with all of your > > > sentiments. You're doing a great job and you are a tremendous asset > > > to this list. Keep up the great work. > > > > Having been a committer to other framework projects, I understand the > > > constant pressure to integrate feature X,Y, and Z. I'm totally on > > > board with the direction the core devs are taking and have faith that > > > the future will see some exciting new developments. > > > > I'm open to any or all solutions to this problem. If I can use a > > > compact pattern or drop in a metaclass somewhere that will enable this > > > functionality then I can certainly live with that. No need to put in > > > man hours maintaining a branch if the solution is a simple tweak to an > > > existing setup. > > > > You're right - "unfortunate" is a value judgement and I really meant > > > it would be unfortunate if lack of a feature drove people away. Of > > > course that happens anyway (what no ajax support? what no clunky > > > templating engine? i pass...) - you know the story. It is very > > > fortunate that we have a solid framework being driven by talented, > > > dedicated people I can tell you that much :) > > > > Cheers > > > -Brian > > > > On May 1, 9:37 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > > > wrote: > > > > > On 5/2/07, Brian Luft <[EMAIL PROTECTED]> wrote: > > > > > > Although I've successfully used the multi-db branch experimentally, it > > > > > looks to be getting more and more out of date with the django trunk. > > > > ... > > > > > Just for the sake of lively discussion, I would go so far as to say > > > > > that only being able to access a singledatabaseper project is an > > > > > unfortunate limitation and could be a deal-breaker for those > > > > > evaluating Django for their own use. I'm sure there are many > > > > > .. > > > > > Limitation; sure. Unfortunate - that's a value judgement. > > > > > The recent Rails/Twitter kurfuffle demonstrates that multi-db support > > > > can be very significant for a certain users. However, my time (and the > > > > time of the other devs, for that matter) is very limited, and our own > > > > itches will always take priority. I have many other features that I > > > > want to see in Django before multi-db (aggregate clauses, schema > > > > evolution, and model inheritance to name just 3). Multi-db just isn't > > > > a priority for any of the ways that I use Django, so there isn't much > > > > incentive for me to spend my time on it. > > > > > The fact that a branch exists demonstrates that the core devs are > > > > willing to entertain the idea of multi-db as a feature. However, it > > > > needs somebody to step up to the plate and finish the job. Ultimately, > > > > this means submitting a branch in a condition suitable for merge back > > > > into the trunk. What does this mean in practice? > > > > > - A branch that is up to date with trunk > > > > - Evidence that the branch has been used by real users, and bugs have > > > > been found and fixed > > > > - The existence of test cases that integrate with existing test > > > > framework. > > > > - Offering to look after the feature for the medium term. > > > > > Once you can convince the core devs that these conditions are met, you > > > > should find the merge back happens pretty quickly - and voila! > > > > multi-db in the trunk. > > > > > Now, before we are flooded with "give me SVN access and I'll do it!" > > > > requests. We aren't going to give SVN access to just anybody that > > > > stands up. We have been down this path, and so far, it seems to be the > > > > single easiest way to make sure you never hear from someone ever again > > > > (witness themultiplecontributors that have offered to finish > > > > schema-evolution). Before you get SVN access, we want to see a track > > > > record of contributing first. > > > > > Getting started doesn't require access to SVN. If you are interested > > > > in multi-db, start working and submit patches. If you demonstrate that > > > > you are in for the long haul, you will get SVN access for that branch > > > > to make your life a little easier. > > > > > So - if you want multi-db (or any other feature, for that matter), have > > > > at it! > > > > > 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 -~----------~----~----~----~------~----~------~--~---
