Re: GSoC - denormalization model field proposal
I didn't know this project, Andrew, thank you. This is a very generic
approach. Very nice.
I figure out that to keep working with class attributes, and keeping the
syntax clean, like I intended, there should be at least three fields
(AggregationField, MirrorField and another one for the 'render html'
example) as discussed in the first thread about denormalization. Or we could
create a field that calls a method (but in this case it would be better to
use a method with a decorator [without an attribute], as in:
http://github.com/initcrash/django-denorm/tree/master).
Daniel Tang posted a nice proposal of using those fields (Aggregation and
MirrorField) so I'll leave for him to finish it the right way (but I don't
agree with him on creating database triggers!).
Good luck, Daniel!
Renato
On Sat, Mar 21, 2009 at 9:07 PM, Andrew Godwin wrote:
>
> Alex Gaynor wrote:
> >
> >
> > class Order(models.Model):
> >...
> >n_items = DenormalizedField(signal_from='itemorder',
> > qs=self.itemorder_set.count())
> >total_price = DenormalizedField(signal_from='itemorder',
> > qs=self.itemorder_set.sum('item_price'))
> >
> >
> > I see a few problems, a) self isn't in scope there, b) sum isn't a
> > method on querysets, I assume you're looking for
> > self.itemorder_set.aggregate(Sum('item_price')
>
> Yup, this is the same classic blunder I made in my initial thought
> experiment. You'll have to find some way of changing the syntax.
>
> >
> > There's been a fair amount of work on this before:
> > http://www.aeracode.org/2008/9/14/denormalisation-follies/ I don't
> > know if you're looking to do significantly more than that, but it
> > doesn't look like there's enough work here for a GSOC project.
>
> There was a more promising solution than mine, as well -
> http://github.com/initcrash/django-denorm/tree/master - where you just
> write a function and stick a decorator around it to make it work. I'm
> not sure if that's the right size of code for a GSoC project either, but
> then I've not seen too many past entries in full.
>
> Andrew
>
>
> >
>
--
Atenciosamente,
Renato Garcia Pedigoni
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
[GSoC] (Another) Denormalized fields proposal
Hi all,
Quick intro: I'm Daniel, a first year PhD student in Computer Science
at Purdue in good ol' Indiana (BS is also in Computer Science). I've
never contributed to the actual Django framework, but I've done some
amount of programming with Django and have subscribed to the mailing
lists/RSS feed for awhile now. I'd like to think I have a fair amount
of knowledge regarding database theory; it helps that I'm taking a
graduate course on databases right now.
I know Renato just posted a proposal for denormalized fields, but I've
been working on my own proposal, following Alex's post as a template.
Our proposals seem to be a bit different though, so I'm going to
include mine below. Feedback would be great. Please forgive slow
replies on my side, because I have another deadline coming up on
Monday. I'll do my best to answer shorter feedback more promptly. My
proposal is not entirely comprehensive, but I wanted to get some
initial feedback ASAP, rather than waiting for a complete one,
especially given that what I already have seems quite long.
Thanks,
Dan
P.S. Andrew pointed out another denormalization project aside from his
in response to Renato. I think my idea (which was more or less created
from combining others' ideas from the previous thread) takes on a
different approach and includes trigger support. I *think* that
addresses the worry about the project being proportional to a standard
GSoC project. Admittedly, if people don't find trigger support to ever
be necessary, the django-denorm project is probably a much better
implementation. At first glance, it seems like it would be difficult
to implement trigger support in django-denorm.
Denormalized Fields for Django
==
Denormalized fields were previously brought up last year on the
mailing list (see
http://groups.google.com/group/django-developers/browse_thread/thread/9a672d5bbbe67562).
There was quite a bit of discussion, but not much code came out of it.
I'm hoping to take this on as a GSoC project to complete the ideas
that were discussed in the thread. The thread has a lot of ideas from
it, so I am of course not claiming them to be mine.
Denormalization Requirements
The original idea that sparked the discussion was simply allow a model
to store an automatically synchronized copy of a field from another
model. For example, many forum applications will display the owner of
a thread or the name of the latest poster. To reduce query count, a
``Thread`` object could store a username alongside a foreign key to
the thread owner, for example.
The mailing list discussion brought about another use case for
denormalization: storing aggregates in the database. One good example
where this is highly desirable is in a forum application, where the
index of a forum typically will show a thread count and/or a post
count.
Lastly, in case of emergency, there should be a way to check and
repair the consistency of denormalized fields.
Denormalization API
---
It was suggested that one field be used for all types of
denormalization, but I am inclined to disagree. Having one field for
each type listed in the requirements provides a clearer understanding
of what the field is doing, rather than having one field that has more
responsibility. Thus, I suggest a ``MirrorField`` and a
``AggregateField`` for the API. It should be obvious that the intent
of a ``MirrorField`` is to reflect the desired field from another
model, while ``AggregateField`` represents an aggregate query.
Specifically, ``AggregateField`` corresponds to an ``annotate``
clause, *not* an ``aggregate`` clause. An example below to illustrate
the examples I previously stated:
class Forum(models.Model):
thread_count = models.AggregateField(Count('thread'))
post_count = models.AggregateField(Count('thread__post'))
class Thread(models.Model):
forum = models.ForeignKey(Forum)
owner = models.ForeignKey(User)
owner_name = models.MirrorField('owner__username')
class Post(models.Model):
thread = models.ForeignKey(Thread)
The required argument to a ``MirrorField`` is a string referencing the
field to be mirrored, using the same syntax (double underscores) as an
F() expression. The required argument to an ``AggregateField`` is any
single aggregate expression allowed in an ``annotate`` clause.
Optional arguments to ``MirrorField``:
1. ``MirrorField.update``: a boolean argument that indicates whether
or not a denormalized field should be automatically updated when the
referenced value is updated. If ``True``, the field updates when the
referencing object or the foreign key are modified. Defaults to
``True``.
Optional arguments to ``AggregateField``:
1. ``AggregateField.store``: a boolean argument that indicates whether
or not an aggregate calculation is stored. If ``False``, it basically
becomes a shortcut for ``annotate``. Defaults to ``True``.
2. ``AggregateField.update``: simil
Re: GSoC - denormalization model field proposal
Hello, Alex!
> class Order(models.Model):
>>...
>>n_items = DenormalizedField(signal_from='itemorder',
>> qs=self.itemorder_set.count())
>>total_price = DenormalizedField(signal_from='itemorder',
>> qs=self.itemorder_set.sum('item_price'))
>>
>>
> I see a few problems, a) self isn't in scope there, b) sum isn't a method
> on querysets, I assume you're looking for
> self.itemorder_set.aggregate(Sum('item_price')
>
a) I didn't realized it before. I'll think in a neat way to do it.
b) Oops, I had .count() on my mind... did it wrong sorry.
There's been a fair amount of work on this before:
> http://www.aeracode.org/2008/9/14/denormalisation-follies/ I don't know if
> you're looking to do significantly more than that, but it doesn't look like
> there's enough work here for a GSOC project.
I think Andrew Godwin didn't implement a field to store aggregations, only
to copy fields from related tables. And about "not enough work for a GSoC
project"... I chose this project following
http://code.djangoproject.com/wiki/SummerOfCode2009 and after a talk with
Jacob, he said it could be a "great project for GSoC".
Just my thoughts,
> Alex
>
Thank you, Alex. I'll think how to solve the problem you've spotted and try
to implement it even out of GSoC.
--
Atenciosamente,
Renato Garcia Pedigoni
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: GSoC - denormalization model field proposal
Alex Gaynor wrote:
>
>
> class Order(models.Model):
>...
>n_items = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.count())
>total_price = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.sum('item_price'))
>
>
> I see a few problems, a) self isn't in scope there, b) sum isn't a
> method on querysets, I assume you're looking for
> self.itemorder_set.aggregate(Sum('item_price')
Yup, this is the same classic blunder I made in my initial thought
experiment. You'll have to find some way of changing the syntax.
>
> There's been a fair amount of work on this before:
> http://www.aeracode.org/2008/9/14/denormalisation-follies/ I don't
> know if you're looking to do significantly more than that, but it
> doesn't look like there's enough work here for a GSOC project.
There was a more promising solution than mine, as well -
http://github.com/initcrash/django-denorm/tree/master - where you just
write a function and stick a decorator around it to make it work. I'm
not sure if that's the right size of code for a GSoC project either, but
then I've not seen too many past entries in full.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: GSoC - denormalization model field proposal
On Sat, Mar 21, 2009 at 6:46 PM, Renato Garcia Pedigoni <
renatopedig...@gmail.com> wrote:
>
> Hi folks,
>
> My name is Renato, 21, currently studying Biomedical Informatics at
> the University of São Paulo, Brazil. I'm submitting in the next week
> my proposal to GSoC, to create a denormalized model field, like
> discussed in
> http://groups.google.com/group/django-developers/browse_thread/thread/9a672d5bbbe67562/39c7663e9efdc204
> .
>
> My idea is to create only *one generic field*, called
> "DenormalizedField", using this syntax:
>
> class Order(models.Model):
>...
>n_items = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.count())
>total_price = DenormalizedField(signal_from='itemorder',
> qs=self.itemorder_set.sum('item_price'))
>
>
I see a few problems, a) self isn't in scope there, b) sum isn't a method on
querysets, I assume you're looking for
self.itemorder_set.aggregate(Sum('item_price')
>
> And we could use the same way to mirror a field, something like:
> class Order(models.Model):
>customer = models.ForeignKey(Customer)
>customer_name = models.DenormalizedField(signal_from='customer',
> qs=self.customer.name)
>...
>
> And again:
> class Article(models.Model):
>text = models.TextField()
>text_rendered = models.DenormalizedField(signal_from='self',
> qs=self.text.render())
>
> - I don't know wheter the param name 'qs' would be right for these
> situations.
>
> If possible, I'd like some feedback before submitting it.
>
> Thank you all :)
>
> Renato
>
> >
>
There's been a fair amount of work on this before:
http://www.aeracode.org/2008/9/14/denormalisation-follies/ I don't know if
you're looking to do significantly more than that, but it doesn't look like
there's enough work here for a GSOC project.
Just my thoughts,
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
GSoC - denormalization model field proposal
Hi folks,
My name is Renato, 21, currently studying Biomedical Informatics at
the University of São Paulo, Brazil. I'm submitting in the next week
my proposal to GSoC, to create a denormalized model field, like
discussed in
http://groups.google.com/group/django-developers/browse_thread/thread/9a672d5bbbe67562/39c7663e9efdc204.
My idea is to create only *one generic field*, called
"DenormalizedField", using this syntax:
class Order(models.Model):
...
n_items = DenormalizedField(signal_from='itemorder',
qs=self.itemorder_set.count())
total_price = DenormalizedField(signal_from='itemorder',
qs=self.itemorder_set.sum('item_price'))
And we could use the same way to mirror a field, something like:
class Order(models.Model):
customer = models.ForeignKey(Customer)
customer_name = models.DenormalizedField(signal_from='customer',
qs=self.customer.name)
...
And again:
class Article(models.Model):
text = models.TextField()
text_rendered = models.DenormalizedField(signal_from='self',
qs=self.text.render())
- I don't know wheter the param name 'qs' would be right for these
situations.
If possible, I'd like some feedback before submitting it.
Thank you all :)
Renato
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Serving static files with handler-specific sendfile()
A Ruby developer has a blog post on that:
http://john.guen.in/svn/plugins/x_send_file/lib/
.
No compromises there,
:render => { :nothing => true }
(don't return anything in the content).
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: [GSoC] Ticket #5929 (Previously Serialization Refactor)
On Sat, 2009-03-21 at 23:16 +0530, Madhusudan C.S wrote: > Hi Malcolm and all, >Doesn't ticket #5929 (http://code.djangoproject.com/ticket/5929) > look very similar to what I proposed for Python? Allowing Python > built in complex datatype objects to be mapped to Relational > Database (which includes lists, dictionaries and tuples)? May > be an additional abstraction along with what is proposed in the > ticket? That's a valid feature request and something we'll definitely implement, but it's not an obvious consequence of your previous post, since it's really got nothing to do with serialisation. It's a well-known ticket / feature request, but there are plenty of other well-known tickets and I haven't assumed they're part of your proposal, either. I've been trying to still work out what it is you're proposing to work on. "Something to do with serialisation" and something to solve a problem you're having with an external app seems to be the impression I've gotten so far. You need to come up with something a bit more concrete. "I am going to solve these particular problems as represented by these bugs and/or these mailing list posts showing a common use-case pattern." is the type of thing that would be encouraging. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: defer() and only()
On Sat, 2009-03-21 at 13:09 +0300, Ivan Sagalaev wrote:
> Hello everyone!
>
> Just played with new defer() and only() and noticed that fields deferred
> with only() aren't loaded when asked explicitly. I.e.:
>
> a = Article.objects.defer('text')[0]
> a.text # <-- does a new query as expected
>
> a = Article.objects.only('date')[0]
> a.text # <-- doesn't do a new query
>
> Absent field values in the case of only() contain their respective
> defaults. Is this a bug?
Yes, it's a bug. As soon as you mention "default", I realise I've missed
a path in __init__. I'll fix it today. I suspect there might be a couple
of these sorts of things. By the time I committed that, I was going
dotty from staring at code paths and notes, trying to balance efficiency
in lines of code with completeness, so there might be one or two things
that have slipped through. It's been a couple of days now, so I'll go
back over things and look for what I've missed.
Thanks for spotting this, Ivan.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
On Sat, Mar 21, 2009 at 2:25 PM, James Bennett wrote: > > On Sat, Mar 21, 2009 at 11:24 AM, Alex Gaynor > wrote: > > b) Having the admin be CSRF safe by default doesn't seam like a feature, > it > > feels like a bug, even if it's implementation gives everything a new > > feature. That's just my thoughts though. > > Personally I'd much rather have it actually *be* secure (and usable), > but the current middleware just doesn't really cut it -- the method it > uses is of such narrow applicability (and potentially can be screwed > up by various other middlewares) that I don't think this is the right > way to do it. > > I'd rather see the change backed out and Luke's improvements worked on > to make sure we get something solid before this ends up in a release. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > I think we're agreeing here, Luke was saying he was concerned about having time to get the improvement in since the feature freeze was coming up, I was saying I don't think that needed to be a concern because fixing a possible security issue isn't a feature, it's a bug. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
On Sat, Mar 21, 2009 at 11:24 AM, Alex Gaynor wrote: > b) Having the admin be CSRF safe by default doesn't seam like a feature, it > feels like a bug, even if it's implementation gives everything a new > feature. That's just my thoughts though. Personally I'd much rather have it actually *be* secure (and usable), but the current middleware just doesn't really cut it -- the method it uses is of such narrow applicability (and potentially can be screwed up by various other middlewares) that I don't think this is the right way to do it. I'd rather see the change backed out and Luke's improvements worked on to make sure we get something solid before this ends up in a release. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database API proposal
On Sat, Mar 21, 2009 at 1:45 PM, Eric Florenzano wrote: > > > To me replication is a major use-case. I suspect most people who move > > beyond single server setup and beyond 10'000 - 20'000 visitors realize > > that replication should just be in place ensuring performance and > > redundancy. In my experience other multi-DB patterns (those that covered > > with `using()` and Meta-attributes on models) are just *less* common in > > practice. So I consider leaving replication to "time permitting" a > mistake. > > There's a finite amount of time in GSoC. If he says he will > definitely do it, then something else will probably have to be cut to > make time. Everything else, however, is prerequisite to implementing > the actual replication strategies. > Whether I implement any form of multiple database scheme is immaterial to whether it is implementable. The point of the DatbaseManager concept is that you can implement your own replication scheme easily. > > There are almost two GSoC projects here, wrapped into one. First > there's the plumbing in Django's core that just needs to happen. > Second there's the actual APIs built on top of that plumbing. The > former needs to happen before the latter, but in implementing the > latter, some changes will almost certainly need to be made to the > former as assumptions are challenged and implementation details get in > the way. > > In any case, I think Alex is the one to do this. He's got a +1 from > me (not that it means much now that I'm on Malcolm's special list). > Speaking of Malcolm's special list... > > > One suggestion Eric Florenzano had was that we go above and beyond > > just storing the methods and parameters, we don't even excecute them > > at all until absolutely necessary. > > I wasn't actually making that suggestion, per se. I was just thinking > out loud that _if_ this type of system were implemented, then it would > open the door for some fun computer-sciency things like performing > transitive reductions on the operations performed on the QuerySet. > That being said, I'm not convinced it's the right way to go because of > its significant added complexity, and because it would make poking > around at the Query object more difficult and generally make the Query > object more opaque. > Sorry if I was putting words in you mouth, I merely meant the idea came from you. > > Thanks, > Eric Florenzano > > > Thanks to all, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Minor bug in the documentation
... Hmm... good point, sorry, i'm a nub. > > Please file a ticket and upload a patch, docs changes go through the same > process as any code bug. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
> Too late now since it's already committed, but I've got some serious > reservations about this one. More development effort should have gone > into improving and refactoring the middleware before it got > automatically enabled. I agree with James here. With apologies to Luke, the CSRF middleware needed to be more bulletproof before it was turned on by default. I can't count the number of times since turning on the middleware that I've been greeted with the cryptic "Cross-Site Request Forgery attempt detected" message inexplicably, and every time I try to go and repeat it, I am unable to do so. I suspect that after 1.1 this will be the most common FAQ/Complaint, is people won't understand and will get these types of messages often. Also, I ran into the problem myself where huge swaths of my tests failed due to the CSRF middleware. It took me a bit to realize that it had to do with the CSRF middleware, and if it tripped me up, it's going to trip up other users as well. If we're going to ship CSRF middleware on by default, I propose that we take a second look at the wontfix status of tickets like #9172. Thanks, Eric Florenzano --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Minor bug in the documentation
On Sat, Mar 21, 2009 at 1:45 PM, Randy wrote: > > Just looking over the documentation for the release process and > noticed a small word duplication: > > Index: release-process.txt > === > --- release-process.txt (revision 10112) > +++ release-process.txt (working copy) > @@ -108,7 +108,7 @@ > 1.3.2, etc. > > * Security releases will be applied to trunk, a ``1.3.X`` branch > and a > - ``1.2.X`` branch. Security fixes will trigger the release of of > ``1.3.1``, > + ``1.2.X`` branch. Security fixes will trigger the release of > ``1.3.1``, > ``1.2.1``, etc. > > .. _release-process: > > > > Please file a ticket and upload a patch, docs changes go through the same process as any code bug. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Minor bug in the documentation
Just looking over the documentation for the release process and noticed a small word duplication: Index: release-process.txt === --- release-process.txt (revision 10112) +++ release-process.txt (working copy) @@ -108,7 +108,7 @@ 1.3.2, etc. * Security releases will be applied to trunk, a ``1.3.X`` branch and a - ``1.2.X`` branch. Security fixes will trigger the release of of ``1.3.1``, + ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``, ``1.2.1``, etc. .. _release-process: --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
[GSoC] Ticket #5929 (Previously Serialization Refactor)
Hi Malcolm and all, Doesn't ticket #5929 (http://code.djangoproject.com/ticket/5929) look very similar to what I proposed for Python? Allowing Python built in complex datatype objects to be mapped to Relational Database (which includes lists, dictionaries and tuples)? May be an additional abstraction along with what is proposed in the ticket? That too this ticket being accepted by Jacob gives me a rare kind of feeling that this might be a feature that can be implemented along with what I have written above in my previous mails. I request you all to give your feedback? -- Thanks and regards, Madhusudan.C.S Blogs at: www.madhusudancs.info Official Email ID: madhusu...@madhusudancs.info --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database API proposal
> To me replication is a major use-case. I suspect most people who move > beyond single server setup and beyond 10'000 - 20'000 visitors realize > that replication should just be in place ensuring performance and > redundancy. In my experience other multi-DB patterns (those that covered > with `using()` and Meta-attributes on models) are just *less* common in > practice. So I consider leaving replication to "time permitting" a mistake. There's a finite amount of time in GSoC. If he says he will definitely do it, then something else will probably have to be cut to make time. Everything else, however, is prerequisite to implementing the actual replication strategies. There are almost two GSoC projects here, wrapped into one. First there's the plumbing in Django's core that just needs to happen. Second there's the actual APIs built on top of that plumbing. The former needs to happen before the latter, but in implementing the latter, some changes will almost certainly need to be made to the former as assumptions are challenged and implementation details get in the way. In any case, I think Alex is the one to do this. He's got a +1 from me (not that it means much now that I'm on Malcolm's special list). Speaking of Malcolm's special list... > One suggestion Eric Florenzano had was that we go above and beyond > just storing the methods and parameters, we don't even excecute them > at all until absolutely necessary. I wasn't actually making that suggestion, per se. I was just thinking out loud that _if_ this type of system were implemented, then it would open the door for some fun computer-sciency things like performing transitive reductions on the operations performed on the QuerySet. That being said, I'm not convinced it's the right way to go because of its significant added complexity, and because it would make poking around at the Query object more difficult and generally make the Query object more opaque. Thanks, Eric Florenzano --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
On Sat, Mar 21, 2009 at 12:20 PM, Luke Plant wrote: > > Hi Adrian, > > On Saturday 21 March 2009 01:47:08 Adrian Holovaty wrote: > > > I've been traveling since Tuesday, and, shall we say, I'm not that > > excited about this being in the default middleware. In fact, I'm +1 > > for reverting this change and might even want to exercise the > > benevolent dictator veto on it, frankly. > > > > My reasoning: it's more overhead for every request, and it's a > > clunky implementation. I mean, parsing the HTML of every page with > > a regex? Come on. > > > > We ought to be making Django *faster*, not adding little pieces to > > it, bit by bit, until it gets bloated. > > > > And to raise a bit of bureaucracy in the process: there's something > > particularly Big And Important about changing anything in the > > global settings file -- whether it's adding a new setting, or > > changing a setting as fundamental as MIDDLEWARE_CLASSES -- so in > > the future I would ask that any such changes be given more > > discussion (and signoffs by committers) before a quick commit. In > > fact, it should be entirely opt-in, not opt-out. "Please let me > > know by Thursday evening (GMT) if there are objections" is not > > acceptable, IMO. > > My apologies. I thought that most people were already using this > middleware, and given that this is a security bug (#510) which you > closed nearly three years ago solely on the basis of this middleware > being used, I didn't realise changing this default was so contentious. > But I certainly should have approached getting support for the > proposal differently. I'm happy to revert it myself, I'm in no way > emotionally attached to it! > > On the other hand, I think I could give most of Monday to implementing > the template tag and fixing up the admin app to use it, eliminating > the need for the (more) contentious part of this commit. That's past > the deadline for the beta, though (the reason for my hasty commit in > the first place), and it would still need review from other people > before it goes in. > > Regards, > > Luke > > -- > OSBORN'S LAW >Variables won't, constants aren't. > > Luke Plant || http://lukeplant.me.uk/ > > > > > a) The beta was pushed back to monday at noonish. b) Having the admin be CSRF safe by default doesn't seam like a feature, it feels like a bug, even if it's implementation gives everything a new feature. That's just my thoughts though. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
Hi Adrian, On Saturday 21 March 2009 01:47:08 Adrian Holovaty wrote: > I've been traveling since Tuesday, and, shall we say, I'm not that > excited about this being in the default middleware. In fact, I'm +1 > for reverting this change and might even want to exercise the > benevolent dictator veto on it, frankly. > > My reasoning: it's more overhead for every request, and it's a > clunky implementation. I mean, parsing the HTML of every page with > a regex? Come on. > > We ought to be making Django *faster*, not adding little pieces to > it, bit by bit, until it gets bloated. > > And to raise a bit of bureaucracy in the process: there's something > particularly Big And Important about changing anything in the > global settings file -- whether it's adding a new setting, or > changing a setting as fundamental as MIDDLEWARE_CLASSES -- so in > the future I would ask that any such changes be given more > discussion (and signoffs by committers) before a quick commit. In > fact, it should be entirely opt-in, not opt-out. "Please let me > know by Thursday evening (GMT) if there are objections" is not > acceptable, IMO. My apologies. I thought that most people were already using this middleware, and given that this is a security bug (#510) which you closed nearly three years ago solely on the basis of this middleware being used, I didn't realise changing this default was so contentious. But I certainly should have approached getting support for the proposal differently. I'm happy to revert it myself, I'm in no way emotionally attached to it! On the other hand, I think I could give most of Monday to implementing the template tag and fixing up the admin app to use it, eliminating the need for the (more) contentious part of this commit. That's past the deadline for the beta, though (the reason for my hasty commit in the first place), and it would still need review from other people before it goes in. Regards, Luke -- OSBORN'S LAW Variables won't, constants aren't. Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
hi
Hey, Checkout www.RemindMeSam.com . -- Amit Upadhyay Via - www.remindmesam.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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [GSOC] Multiple Database API proposal
Alex Gaynor wrote: > 8) Time permitting implement a few common replication patterns. I'm kind of not very excited with this point. To me replication is a major use-case. I suspect most people who move beyond single server setup and beyond 10'000 - 20'000 visitors realize that replication should just be in place ensuring performance and redundancy. In my experience other multi-DB patterns (those that covered with `using()` and Meta-attributes on models) are just *less* common in practice. So I consider leaving replication to "time permitting" a mistake. On the other hand may be all this work won't break mysql_replicated and I'll just have to update it to the new db backend interface. There may be non-trivial things to work out though such as having separate master-slave pairs for each data shard. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
defer() and only()
Hello everyone!
Just played with new defer() and only() and noticed that fields deferred
with only() aren't loaded when asked explicitly. I.e.:
a = Article.objects.defer('text')[0]
a.text # <-- does a new query as expected
a = Article.objects.only('date')[0]
a.text # <-- doesn't do a new query
Absent field values in the case of only() contain their respective
defaults. Is this a bug?
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
