Re: Branches on Github

[Malcolm Tredinnick]

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 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.
> composite primary keys).

You would have one branch that is the mirror of Django's subversion
repository and another branch that is your working branch. Periodically,
you run "git svn rebase" against the mirror branch and then merge that
into your working public branch.

The reason for the two branches is that "git svn rebase" is, as the name
suggests, as rebase (thus pushing all your local modifications to the
top of the tree each time). So if anybody follows your particular branch
of development, it would be better to publish a more stable branch,
which means merging in the subversion changes, rather than rebasing on
the version that people are following.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Branches on Github

[David Cramer]

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.
composite primary keys).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Steve Holden]

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 the correct number
>>> of database columns at table creation time. We have perfect information
>>> when we create the table, which is where this differs from any generic
>>> relations.
>>> [...]
>>>   
>> Does that apply even to recursive (reflexive) relationships, when the
>> related model must be specified by name rather than by reference? I
>> don't know enough about the internals to be clear on that, but it seems
>> like it could be problematic.
>> 
>
> It needs to be taken into account, but it's certainly solvable and not
> an obstacle to success. There are two solutions available:
>
> (1) Postpone creating the first table until we have read the second
> table so that we know the number of columns. This isn't too hard,
> although it means you end up making two passes over some classes'
> internals in some cases. But table creation is such a rare event and the
> Python code is so fast that it's easily affordable. We're not talking
> about something changing from 15 minutes to 20 minutes or anything.
>   
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.
> (2) The poor-man's approach is "ALTER TABLE", which is a small-ish
> change, but butt ugly. I prefer the former solution, but the this is the
> silly drop-in I've got at the moment just to make things possible to
> develop with.
>   
I can see why, from a purist point of view, you'd rather not use it.
Doesn't mean it couldn't be useful as a first implementation, though.
> Realise that the reason we have string-ified forwards references is to
> avoid the need for circular imports. But at some point we'll end up
> importing everything anyway and then we can go and look at the number of
> required columns. This is why forwards references work in the first
> place -- at a later time we go back and fix up the internal references
> to point to the Python objects in question. We can change table creation
> to operate similarly. It's not that hard.
>
>   
I understand that. I just don't have the smarts to be able to help right
now, but thanks for the explanations.

regards
 Steve


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Malcolm Tredinnick]

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 database columns at table creation time. We have perfect information
> > when we create the table, which is where this differs from any generic
> > relations.
> > [...]
> Does that apply even to recursive (reflexive) relationships, when the
> related model must be specified by name rather than by reference? I
> don't know enough about the internals to be clear on that, but it seems
> like it could be problematic.

It needs to be taken into account, but it's certainly solvable and not
an obstacle to success. There are two solutions available:

(1) Postpone creating the first table until we have read the second
table so that we know the number of columns. This isn't too hard,
although it means you end up making two passes over some classes'
internals in some cases. But table creation is such a rare event and the
Python code is so fast that it's easily affordable. We're not talking
about something changing from 15 minutes to 20 minutes or anything.

(2) The poor-man's approach is "ALTER TABLE", which is a small-ish
change, but butt ugly. I prefer the former solution, but the this is the
silly drop-in I've got at the moment just to make things possible to
develop with.

Realise that the reason we have string-ified forwards references is to
avoid the need for circular imports. But at some point we'll end up
importing everything anyway and then we can go and look at the number of
required columns. This is why forwards references work in the first
place -- at a later time we go back and fix up the internal references
to point to the Python objects in question. We can change table creation
to operate similarly. It's not that hard.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Steve Holden]

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 keys and the two
> shouldn't be merged.
> 
> Generic Relations say how to get from an object id and a content type to
> a remote object. They aren't a database-layer construct, although a
> database constraint to, e.g., the content-type table could be
> enforced(but that's not relevant here). ForeignKeys are a representation
> of a database constraint, always referring to same remote table. They
> are necessarily different concepts and I dont' think attempting to merge
> them is going to gain much in clarity. At some point when multi-column
> primary keys are supported, we might be able to work out a way for
> generic relations to handle them, but I'm not holding my breath about
> that and it's certainly a phase 2 or phase 3 thing. The reason it's
> almost impossible to support generic relations with arbitrary
> multi-column fields because the number of columns is, well, arbitrary
> (attempting to jam multiple remote values into one local database column
> is a bad idea, too. At some point the hacks mount up beyond the point of
> usefulness). That is, one content type requires one value, a different
> one requires two and a third content type might require four values to
> identify the object. I strongly suspect we'll end up just saying
> GenericRelation fields only work for single valued objects ids. Which
> isn't at all unreasonable, since Django's generic relation classes
> aren't really compulsory for data modelling. Any given situation has a
> solution that doesn't involve them.
> 
>>  Although the more I think about it we'd still want to
>> magically handle ForeignKey's so the same problem exists.
> 
> There's no magic in programming. :-)
> 
> 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 database columns at table creation time. We have perfect information
> when we create the table, which is where this differs from any generic
> relations.
> [...]
Does that apply even to recursive (reflexive) relationships, when the
related model must be specified by name rather than by reference? I
don't know enough about the internals to be clear on that, but it seems
like it could be problematic.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[David Cramer]

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 (but this can sit on the backburner IMHO).

Anyways, adding the fields "transparently" (thats what I meant) is
easy. I've done it quite a bit in my own code. I spent several hours
however, trying to find a way to make ".filter(pk=(1,2,3))", ".filter
(pk=dict(blah=1, blah2=2, blah3=3))" work, however. That is the
specific area I've been waiting on. I have however had lots of time to
find various random admin bugs which I've been slowly fixing up.
Filters/etc are all working in my local version.

On Nov 13, 10:14 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
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 keys and the two
> shouldn't be merged.
>
> Generic Relations say how to get from an object id and a content type to
> a remote object. They aren't a database-layer construct, although a
> database constraint to, e.g., the content-type table could be
> enforced(but that's not relevant here). ForeignKeys are a representation
> of a database constraint, always referring to same remote table. They
> are necessarily different concepts and I dont' think attempting to merge
> them is going to gain much in clarity. At some point when multi-column
> primary keys are supported, we might be able to work out a way for
> generic relations to handle them, but I'm not holding my breath about
> that and it's certainly a phase 2 or phase 3 thing. The reason it's
> almost impossible to support generic relations with arbitrary
> multi-column fields because the number of columns is, well, arbitrary
> (attempting to jam multiple remote values into one local database column
> is a bad idea, too. At some point the hacks mount up beyond the point of
> usefulness). That is, one content type requires one value, a different
> one requires two and a third content type might require four values to
> identify the object. I strongly suspect we'll end up just saying
> GenericRelation fields only work for single valued objects ids. Which
> isn't at all unreasonable, since Django's generic relation classes
> aren't really compulsory for data modelling. Any given situation has a
> solution that doesn't involve them.
>
> >  Although the more I think about it we'd still want to
> > magically handle ForeignKey's so the same problem exists.
>
> There's no magic in programming. :-)
>
> 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 database columns at table creation time. We have perfect information
> when we create the table, which is where this differs from any generic
> relations.
>
> > I guess I could write a composite foreign key manager, which could be
> > used in both instances. The problem is the API is very confusing at
> > the moment, and I haven't been able to work out a good way to handle
> > (in the code) mycomposite__exact=1 (single to multiple relation
> > lookup). Maybe you could help with this :)
>
> The value on the right hand side can be any sequence or tuple (or even
> an object that knows how to return a sequence or tuple). The ORM will
> know that the field involved is a multicolumn field and know to expect
> multiple values on the RHS to associate with the multiple LHS columns.
> It doesn't make sense to say mycomposite__exact=1, since mycomposite
> expects multiple values. It's clear what
>
>         mycomposite__exact = (1,2)
>
> means, however.
>
> I will finish my work on this when I get a chance and as soon as
> possible. I realise you've been waiting for a bit. Haven't had a lot of
> time for Django the past few weeks, but I'm getting back on the horse
> again now, although there'll be a bit of focus on 1.1 feature triage and
> 1.0.X for a little bit first.
>
> It doesn't mean that you need to specify the primary key columns on the
> ForeignKey field, though. As I pointed out in the original message, you
> know which are the primary key columns because they're declared on the
> model referred to.
>
>
>
> > Really, this issue is all thats stopping me from completing the
> > composite PKs patch.
>
> You should still have something that's in multiple portions, though.
> Relations are kind of a second phase to the rest. So you could open a
> ticket with the first part of the patch if you want some early review on
> that (although you've missed the 1.1 window now, so it will be
> deprioritised a little bit officially, but I'm still 

Re: Feature reviews for 1.1

[David Cramer]

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 PROTECTED]>
wrote:
> 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 the features on this list, just let me
> know; no need to rank 'em all. Remember that features without a
> champion and implementor simply won't get done. So if you see one you
> can do, volunteer to take it up!
>
> Jacob
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Malcolm Tredinnick]

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.

Generic Relations say how to get from an object id and a content type to
a remote object. They aren't a database-layer construct, although a
database constraint to, e.g., the content-type table could be
enforced(but that's not relevant here). ForeignKeys are a representation
of a database constraint, always referring to same remote table. They
are necessarily different concepts and I dont' think attempting to merge
them is going to gain much in clarity. At some point when multi-column
primary keys are supported, we might be able to work out a way for
generic relations to handle them, but I'm not holding my breath about
that and it's certainly a phase 2 or phase 3 thing. The reason it's
almost impossible to support generic relations with arbitrary
multi-column fields because the number of columns is, well, arbitrary
(attempting to jam multiple remote values into one local database column
is a bad idea, too. At some point the hacks mount up beyond the point of
usefulness). That is, one content type requires one value, a different
one requires two and a third content type might require four values to
identify the object. I strongly suspect we'll end up just saying
GenericRelation fields only work for single valued objects ids. Which
isn't at all unreasonable, since Django's generic relation classes
aren't really compulsory for data modelling. Any given situation has a
solution that doesn't involve them.

>  Although the more I think about it we'd still want to
> magically handle ForeignKey's so the same problem exists.

There's no magic in programming. :-)

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 database columns at table creation time. We have perfect information
when we create the table, which is where this differs from any generic
relations.

> I guess I could write a composite foreign key manager, which could be
> used in both instances. The problem is the API is very confusing at
> the moment, and I haven't been able to work out a good way to handle
> (in the code) mycomposite__exact=1 (single to multiple relation
> lookup). Maybe you could help with this :)

The value on the right hand side can be any sequence or tuple (or even
an object that knows how to return a sequence or tuple). The ORM will
know that the field involved is a multicolumn field and know to expect
multiple values on the RHS to associate with the multiple LHS columns.
It doesn't make sense to say mycomposite__exact=1, since mycomposite
expects multiple values. It's clear what

mycomposite__exact = (1,2)

means, however.

I will finish my work on this when I get a chance and as soon as
possible. I realise you've been waiting for a bit. Haven't had a lot of
time for Django the past few weeks, but I'm getting back on the horse
again now, although there'll be a bit of focus on 1.1 feature triage and
1.0.X for a little bit first.

It doesn't mean that you need to specify the primary key columns on the
ForeignKey field, though. As I pointed out in the original message, you
know which are the primary key columns because they're declared on the
model referred to.

> 
> Really, this issue is all thats stopping me from completing the
> composite PKs patch.

You should still have something that's in multiple portions, though.
Relations are kind of a second phase to the rest. So you could open a
ticket with the first part of the patch if you want some early review on
that (although you've missed the 1.1 window now, so it will be
deprioritised a little bit officially, but I'm still interested in
coming to some conclusion on this).

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[David Cramer]

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 foreign key manager, which could be
used in both instances. The problem is the API is very confusing at
the moment, and I haven't been able to work out a good way to handle
(in the code) mycomposite__exact=1 (single to multiple relation
lookup). Maybe you could help with this :)

Really, this issue is all thats stopping me from completing the
composite PKs patch.

On Nov 13, 7:19 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> 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)
> >     name = models.TextField()
>
> > class MyModel:
> >     pk_part1 = models.IntegerField()
> >     pk_part2 = models.ForeignKey(MyModel2)
>
> >     mymodel3 = models.CompositeForeignKey(MyModel3, pk_part1=pk_part1,
> > pk_part2=pk_part2)
>
> Why is the primary key specified on the relation field, rather than just
> being part of MyModel3? A model has a primary key, and the foreign
> relation should use that in the natural case. It's not a property of the
> relation, it's a property of the target model and should be declared
> there.
>
> There might be an argument for a multi-column version of to-field, but a
> tuple or list would seem the easiest way of specifying that, rather than
> a variable number of arguments.
>
> At that point, I think normal ForeignKey fields could be adjusted to
> Just Work(tm), since they'll know they're related to a model with a
> multi-column primary key.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Malcolm Tredinnick]

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)
> name = models.TextField()
> 
> class MyModel:
> pk_part1 = models.IntegerField()
> pk_part2 = models.ForeignKey(MyModel2)
> 
> mymodel3 = models.CompositeForeignKey(MyModel3, pk_part1=pk_part1,
> pk_part2=pk_part2)

Why is the primary key specified on the relation field, rather than just
being part of MyModel3? A model has a primary key, and the foreign
relation should use that in the natural case. It's not a property of the
relation, it's a property of the target model and should be declared
there.

There might be an argument for a multi-column version of to-field, but a
tuple or list would seem the easiest way of specifying that, rather than
a variable number of arguments.

At that point, I think normal ForeignKey fields could be adjusted to
Just Work(tm), since they'll know they're related to a model with a
multi-column primary key.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

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

[Malcolm Tredinnick]

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 users session, vs whoever else happens
> to visit that url (say I pass it off to a coworker).

This last point is exactly why putting it in the URL is the better
solution. It's the whole idea behind addressable resources. You can then
pass around the right filtered view to a colleague via email for further
work. Or you can record it in an issue tracker. Or bookmark it to come
back to later on.

Storing it in the session would throw away all those benefits. We're
developing for the web here; let's use the advantages of the medium,
rather than doing all the work and then only making it available to the
single person viewing it at that moment.

Persistent filters makes sense; we should do that. But in the URL if at
all possible, since it's best practice.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: pimentech's libcommonDjango JSONRPC Service

[Malcolm Tredinnick]

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 neglected to explain what the module was about or why it's
necessary. So I had to download the tarball and then try to visit a
website to find out things like the license, etc (since the website
wasn't responding, I don't know that, still, but it turned out to be
moot, since I don't think this is really a candidate for inclusion).
It's a single file you're talking about that seems to implement an
RPC-over-JSON view, from what I can work out.

I also think you slightly misunderstand the usage of django/contrib/ --
it's for self-contained applications, not single utility file. We don't
use contrib/ like some older-style projects where it becomes a dumping
ground for lots of externally contributed stuff.

> they're important enough

Not at all clear and I would take issue with the claim. The class is
implementing RPC. Django tends to favour more REST-like development
(we're hardly alone in that respect), for a start. Not really a use-case
that is preventing development with Django. However, Django doesn't
enforce any kind of REST architecture in applications (obviously) and
RPC is certainly possible, but it's also easy enough that I don't see
people being held back by the lack of inclusion of a class like this.

>  and small enough to be included in django by
> default, and the code definitely adds value to django.

Given that it's only a single file, why can't the few people who want to
do RPC work just download that particular file, if that's their
preferred implementation? Or even just include it in their applicaiton
that relies on RPC? I'm a fairly strong -1 on including *any* RPC
library in Django itself, since there's really no need and it tends to
go against the "best practices" grain a bit (thereby not adding value). 

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Feature reviews for 1.1

[Jacob Kaplan-Moss]

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 the features on this list, just let me
know; no need to rank 'em all. Remember that features without a
champion and implementor simply won't get done. So if you see one you
can do, volunteer to take it up!

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Translation of documentation

[Jacob Kaplan-Moss]

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 need to accept and maintain
translated documentation. I'll have that done, along with some docs
about how the process works, next week. Stay tuned!

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Translation of documentation

[Guilherme M. Gondim (semente)]

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/).

How the files of the translation should be named (pt_BR/index.txt,
index_pt-br.txt)?

Thanks,
semente

[1] http://django-l10n-portuguese.googlecode.com/svn/branches/docs-1.0.X/

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Feature reviews for 1.1

[Dj Gilcrease]

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
~~http://www.openrpg.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: Composite Foreign Keys

[David Cramer]

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()
pk_part2 = models.ForeignKey(MyModel2)

mymodel3 = models.CompositeForeignKey(MyModel3, pk_part1=pk_part1,
pk_part2=pk_part2)

MyModel.objects.filter(mymodel3__name="Hi")

Anyways, I think you get the gist. I think this would cover all use
cases, and is a very simple, similar, and clean API.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Features for 1.1

[Jacob Kaplan-Moss]

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
asking the other core developers and any other interested developers
to do so as well this week and over the weekend. I'm making a first
pass now to weed out the obviously-not-possible and the simple
bugfixes in that list. I'll write a post here later today about how
I'd like to see the review process work.

* If I get some reviews from other devs in in a timely manner I'll try
to have a draft feature list out Monday, but we're probably looking at
Wednesday or so realistically.

* Yes, we're a few days behind according to the schedule. Oh well.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

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

[suuntala]

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.com/ticket/9460

Mikko
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Denormalisation Magic, Round Two

[Andrew Godwin]

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. models.MirrorField("my_callable_or_attribute") as well as the
> models.MirrorFIeld("my_attribute", "its_subattribute")
>   

Well, callables are a lot harder to deal with; there's no efficient way
to hook onto when they've changed. It would be possible if you passed
along a foreign key to watch for changes, although at that point you
could probably also implement it using an AggregateField of some kind,
since they already take arbitary aggregate functions.

The problem is the 'self' thing, though. However, I like the
filter()-style syntax, I'll need to see if that's easy enough to roll in
so it still makes sense...

Andrew


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---