Re: Final call for feedback: Multi-db

On Tue, Dec 22, 2009 at 4:55 PM, Brett Hoerner wrote: > On Dec 22, 4:27 pm, Russell Keith-Magee > wrote: > > * Allow TEST_NAME=None to mean "don't try and instantiate this > > database in test mode" > > That sounds good, too. > If I was using the

Re: Final Multi-DB status Update

On Thu, Sep 3, 2009 at 5:00 PM, Russell Keith-Magee <freakboy3...@gmail.com>wrote: > > On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer<craig.kime...@gmail.com> > wrote: > > I've spent a little time using this branch and looking at the possibility > of > > using i

Re: Final Multi-DB status Update

I've spent a little time using this branch and looking at the possibility of using it with my project. Below is a short list of problems and ponies that I have encountered (or want). 1. It'd be awesome if we could mark certain databases as slaves. Inserts / deletes / creates / drops would only

Re: BitmaskField

Andrew: Thanks, that looks awesome. The whole BitMaskField(choices=LIST) idea scares me. You must then force extra knowledge on the user that ordering is important. If programmer Y decides the list of choices looks better in alphabetical order (or decides to add a choice in the middle of the

Re: BitmaskField

AM, [EMAIL PROTECTED] wrote: > > > > > > I would use this. The one thing I don't see covered in your example > is > > > > setting flags. I would look at allowing a list or tuple of integers. > > > > Using your example: > > > > > > p = Person

BitmaskField

Apologies if this has been asked already and I have missed it in searching, but is there any interest in taking a patch for a BitmaskField? Given the following (albeit stupid) example to show some usages that would be nice to have on a bitmask field. I should note in the examples below, the