Re: Branches on Github

On Thu, 2008-11-13 at 21:37 -0800, David Cramer wrote: > Not the *best* place to post this, but it does relate to Django dev. > > Is it possible, and if so how, could one branch the Django trunk, and > throw it on Github? Use "git svn". It's standard with git. Very easy to work with. > From wh

Branches on Github

Not the *best* place to post this, but it does relate to Django dev. Is it possible, and if so how, could one branch the Django trunk, and throw it on Github? >From what I've read I could then do some kind of "svn up" to merge in latest changes easily from trunk, and also work on my branch (e.g.

Re: Proposal: Composite Foreign Keys

On Fri, 2008-11-14 at 00:17 -0500, Steve Holden wrote: [...] > Sure. Perhaps it's not common terminology: by "recursive" I meant a > self-referential relationship, though now you mention it I see that the > same issue can occur if the order of model definitions is sub-optimal. The recursive cas

Re: Proposal: Composite Foreign Keys

Malcolm Tredinnick wrote: > On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: > [...] > >>> Maybe be you mean transparently. If so, I think this is a requirement, >>> too, but it's not a problem. We know when the ForeignKey field is >>> specified which model it refers to, so we can include

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote: [...] > > Maybe be you mean transparently. If so, I think this is a requirement, > > too, but it's not a problem. We know when the ForeignKey field is > > specified which model it refers to, so we can include the correct number > > of databas

Re: Proposal: Composite Foreign Keys

Malcolm Tredinnick wrote: > > On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: >> I was thinking beyond just handling Foreign Keys actually when I wrote >> this up. It would allow for a more generic version of a generic >> foreign key. > > Generic relations are quite different to foreign k

Re: Proposal: Composite Foreign Keys

Ya this was more of a two birds one stone goal here. It'd be nice to be able to specify relations (e.g. the filter example), like it would with a generic foreign key, but not restricted to content_type/ object_id. We also will run into the issue with that, where object_id is a composite as well (b

Re: Feature reviews for 1.1

I volunteer for #17! And I have working code for a pretty simplistic message handler which is session vs database based (which is one of the proposals, sort of). So I guess if that's whats wanted, I can mold it to fit what has been discussed. On Nov 13, 5:03 pm, "Jacob Kaplan-Moss" <[EMAIL PROTE

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: > I was thinking beyond just handling Foreign Keys actually when I wrote > this up. It would allow for a more generic version of a generic > foreign key. Generic relations are quite different to foreign keys and the two shouldn't be merged.

Re: Proposal: Composite Foreign Keys

I was thinking beyond just handling Foreign Keys actually when I wrote this up. It would allow for a more generic version of a generic foreign key. Although the more I think about it we'd still want to magically handle ForeignKey's so the same problem exists. I guess I could write a composite for

Re: Proposal: Composite Foreign Keys

On Thu, 2008-11-13 at 10:53 -0800, David Cramer wrote: > Here's my proposal for the composite keys (which act much like generic > keys except more useful): > > class MyModel2: > pass > > class MyModel3: > pk_part1 = models.AutoField() > pk_part2 = models.ForeignKey(MyModel2) > n

Re: Proposal: Make filters in admin persistent (#6903)

On Tue, 2008-11-11 at 13:47 -0800, David Cramer wrote: > Well I'm not sure storing multiple search paths is too good of an > idea, as you increase the size of the session significantly, and then > have to worry about expiring those or clearing them somehow. The > session just keeps it for that us

Re: pimentech's libcommonDjango JSONRPC Service

On Tue, 2008-11-11 at 09:54 -0800, lkcl wrote: > folks, hi, > i wonder if you could kindly include, if nothing else, the > pimentech.network classes, which can be downloaded from > http://lkcl.net/libcommonDjango.tgz in the contrib directory of django > or just as a standard django module. You n

Re: Feature reviews for 1.1

On Thu, Nov 13, 2008 at 1:48 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I'd like to ask committers and anyone else to send me their own rankings. Also: There's no real need for everyone to score everything. In fact, that'll probably be information overload. If you want to work on one of

Re: Translation of documentation

On Thu, Nov 13, 2008 at 3:14 PM, Guilherme M. Gondim (semente) <[EMAIL PROTECTED]> wrote: > Django Project accepts patch for the doc translations? I saw that the > language is provided in URLs of official documentation > (docs.djangoproject.com*/en/*dev/). I'm working on the infrastructure we nee

Translation of documentation

Hi, Django Brazilian Community has started the documentation translation of Django 1.0[1] and serves in . Django Project accepts patch for the doc translations? I saw that the language is provided in URLs of official documentation (docs.djangoproject.com*/en/*dev/).

Re: Feature reviews for 1.1

Just a note about Auth-01, the particular solution I posted is only the first and fastest method I could think to implement the feature of being able to set permissions for the anon user. I care less about the implementation details then I do about the feature. Dj Gilcrease OpenRPG Developer ~~h

Re: Proposal: Composite Foreign Keys

Today i was looking at this. I'll just drop my attempt at the definition API: class Entity: account = models.CharField() number = models.IntegerField() class Meta: primary_key=('account', 'number') class Invoice: number = models.IntegerField() group = models.CharFiel

Feature reviews for 1.1

Hi folks -- I've reorganized the 1.1 feature list (http://code.djangoproject.com/wiki/Version1.1Features) and added "short codes" so we can have a quick shorthand as we review features. I've also reviewed most of the features on the list. I'll talk about the review process -- and how y'all can c

Proposal: Composite Foreign Keys

Here's my proposal for the composite keys (which act much like generic keys except more useful): class MyModel2: pass class MyModel3: pk_part1 = models.AutoField() pk_part2 = models.ForeignKey(MyModel2) name = models.TextField() class MyModel: pk_part1 = models.IntegerField(

Features for 1.1

Hi folks -- A few administrative notes on 1.1: * I've frozen the feature proposal page (this was supposed to happen 11/7 but I was too busy). Folks who missed proposing their pet feature are going to have to wait until 1.2. * I'll be reviewing all the features today and tomorrow, and I'll be as

Re: Proposal: Template block for submit buttons in admin's change_form.html

On Oct 28, 5:37 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Well, that said, don't get carried away... but please do feel free to > open a ticket with a patch adding blocks of this nature. I opened a ticket but forgot to notify here. Well, now I am notifying: http://code.djangoproject.co

Re: Denormalisation Magic, Round Two

David Cramer wrote: > I'm not sure on AggreateField either. What if you just do like > ("Photo", "user__exact=self.user") or something. Currently there's no > rerepsentation for "self" in Django QuerySet's, so this is a hard > thing to call. Also, we need a way to support callables. > > e.g. model