I'll give the merging a shot...then try and see about getting it committed... it might take me a few weeks...since it's my initial voyage through the Django code base, and subversion branches, etc.... plus I still have tons of deadlines at work on top of that :)
At anyrate...when I get all of the changes since the last time merged in...I'll find out what the next steps are about getting it committed. I didn't want to go too far down that path, until I was ready to do so ... On May 2, 12:17 pm, Brian Luft <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
