Re: Class based generic views in 1.3?

[daonb]

On Jun 15, 5:10 pm, Patryk Zawadzki  wrote:
> If you don't mind, I'll talk a bit more to myself.

While talking to self usually helps, IMHO, we have to speak to each
other to get this in 1.3.

Ben has taken the lead of this and published some code. I suggest we
focus on testing and improving Ben's code rather than keep going back
and examine the basic assumptions:

- the url dispatcher will not be changed
- the user will have an thread-safe instance to work with

Actually, the current code is not that sure on the second point,
here's a line from base.py:

view.request = request # FIXME: Maybe remove? Should this be
encouraged?

As I see it, if we're cloning the view, it should be encouraged. I
forked Ben's code and refactored it so that instead of having the
methods pass 'request' around, use self.request. I believe it made the
generic views more readable and it will help users' make their views
cleaner. My fork is at http://github.com/daonb/django-class-based-views


Benny

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Patryk Zawadzki]

On Wed, Jun 16, 2010 at 9:24 AM, daonb  wrote:
> Actually, the current code is not that sure on the second point,
> here's a line from base.py:
>
> view.request = request # FIXME: Maybe remove? Should this be
> encouraged?
>
> As I see it, if we're cloning the view, it should be encouraged. I
> forked Ben's code and refactored it so that instead of having the
> methods pass 'request' around, use self.request. I believe it made the
> generic views more readable and it will help users' make their views
> cleaner. My fork is at http://github.com/daonb/django-class-based-views

I consider using self to store temporary variables a bad design
practice. You wouldn't do that in C++ or Java. Having said that I
might be biased.

If you really want to do such hacks, use threading.local instead of
writing to self directly:

class View(object):
storage = threading.local()
def __call__(self, request, id):
self.storage.request = request
# ...

Cloning objects on each call to a method is a really really really
really bad idea and puts unnecessary stress on the garbage collector
(actually if any of the methods are careless enough to pass self to an
external function, it might result in a steady leak of non-freeable
memory).

-- 
Patryk Zawadzki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello.

On 16/06/10 01:33, Graham Dumpleton wrote:
> Paste has its own problems. Paste server itself does process
> environment setup that isn't done by other WSGI hosting mechanisms.
> Specifically, it initialises Python logging in a way suited to Paste
> based applications. Like with Django development server, you can
> develop a Paste based application on Paste server which will then not
> work on other WSGI hosting mechanisms.
>   

Paste Script will set up logging its way if and only if you explicitly
tell it to; i.e., defining logging configuration in the Paste Deploy
file or passing an argument to `paster'. I cannot think of another thing
that it does at startup time which may affect deployment, but I may be
wrong.

I think there's always the risk of things working on a development
server but not on the production environment, but the thing is how that
risk can be minimized.


> There certainly is a larger problem I also want to address beyond
> pointing out the issues with Django deployment, but I haven't even
> mentioned them in these posts and don't intend to.
>
> What you are trying to do with using Paste Script/Deploy is tinkering
> at the edges of a larger issue you probably don't even know exists or
> don't appreciate. Paste Script/Deploy will not solve that larger issue
> as there are lots of things it doesn't do. Adopting it will only make
> it harder to solve the real problems later on.
>
> Trying to address the bigger issue is going to need some cooperation
> between all frameworks and hosting solution authors to come up with a
> consistent way of doing certain stuff. Right now though I don't have
> time to lay out properly what the issues are or implement a proof of
> concept which illustrates the direction one could take to solve the
> problem. It may be the case that Paste Script/Deploy could be adapted
> to meet that requirement at some point, but by itself, because the
> focus of Paste Deploy is more about constructing WSGI components
> together to create an application, as opposed to solving the problem
> of deployment on a specific hosting mechanism, I feel right now it is
> a poor choice.
>
> If time allows I hope to talk to Russell about some of this stuff when
> he is at PyCon in Sydney, but it will still need a lot more work after
> that.
>
> Ultimately if something doesn't get done to address the bigger issues,
> the WSGI deployment (distinct from composing together WSGI components
> into an application), will continue to be a dogs breakfast.
>   

I have no idea what those problems are, so I never meant to solve them.
I just found two issues and Paste Deploy/Script seemed like a solution.

I'm curious about them though. I'll keep an eye on your blog and Web-SIG.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: 'exists' parameter for pre_save signal

[George Sakkis]

On Jun 16, 4:51 am, Jeremy Dunck  wrote:

> On Tue, Jun 15, 2010 at 10:46 AM, George Sakkis  
> wrote:
> > ...In the current save_base()
> > implementation, pre_save is sent before the instance's existence is
> > determined, so I'm not sure if postponing it would break existing
> > code. If there is no backwards compatibility issue, I can open a
> > ticket and send a patch for it.
>
> Well, a significant difference is that pre_save right now can cancel a
> save before a query to determine existence is needed (0 vs 1 or 2
> queries).  I'm not sure how many people really use pre_save's
> cancellation feature, but I think we'd need some confidence that
> moving wouldn't cause a problem for people counting on the 0-query
> cancellation that's available right now.

I see how this might be an issue for some, but my guess/belief is that
often the existence or not of the instance is necessary to determine
whether the save should be canceled. Besides, the incurred cost is at
most one exists() query, which in 1.2 at least is quite lightweight.

In any case, I opened a ticket and attached a patch (with updated
tests) at http://code.djangoproject.com/ticket/13772.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: First-class WSGI support in Django 1.3 / twod.wsgi

[Graham Dumpleton]

On Jun 16, 7:32 pm, Gustavo Narea 
wrote:
> Hello.
>
> On 16/06/10 01:33, Graham Dumpleton wrote:
>
> > Paste has its own problems. Paste server itself does process
> > environment setup that isn't done by other WSGI hosting mechanisms.
> > Specifically, it initialises Python logging in a way suited to Paste
> > based applications. Like with Django development server, you can
> > develop a Paste based application on Paste server which will then not
> > work on other WSGI hosting mechanisms.
>
> Paste Script will set up logging its way if and only if you explicitly
> tell it to; i.e., defining logging configuration in the Paste Deploy
> file or passing an argument to `paster'. I cannot think of another thing
> that it does at startup time which may affect deployment, but I may be
> wrong.

But that will not happen if you use a different hosting mechanism.
Thus you end up with a fiddle as documented in:

  http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi

The point I am making is that these hosting system specific fiddles
should never need to be done by a user.

Graham

> I think there's always the risk of things working on a development
> server but not on the production environment, but the thing is how that
> risk can be minimized.
>
>
>
>
>
> > There certainly is a larger problem I also want to address beyond
> > pointing out the issues with Django deployment, but I haven't even
> > mentioned them in these posts and don't intend to.
>
> > What you are trying to do with using Paste Script/Deploy is tinkering
> > at the edges of a larger issue you probably don't even know exists or
> > don't appreciate. Paste Script/Deploy will not solve that larger issue
> > as there are lots of things it doesn't do. Adopting it will only make
> > it harder to solve the real problems later on.
>
> > Trying to address the bigger issue is going to need some cooperation
> > between all frameworks and hosting solution authors to come up with a
> > consistent way of doing certain stuff. Right now though I don't have
> > time to lay out properly what the issues are or implement a proof of
> > concept which illustrates the direction one could take to solve the
> > problem. It may be the case that Paste Script/Deploy could be adapted
> > to meet that requirement at some point, but by itself, because the
> > focus of Paste Deploy is more about constructing WSGI components
> > together to create an application, as opposed to solving the problem
> > of deployment on a specific hosting mechanism, I feel right now it is
> > a poor choice.
>
> > If time allows I hope to talk to Russell about some of this stuff when
> > he is at PyCon in Sydney, but it will still need a lot more work after
> > that.
>
> > Ultimately if something doesn't get done to address the bigger issues,
> > the WSGI deployment (distinct from composing together WSGI components
> > into an application), will continue to be a dogs breakfast.
>
> I have no idea what those problems are, so I never meant to solve them.
> I just found two issues and Paste Deploy/Script seemed like a solution.
>
> I'm curious about them though. I'll keep an eye on your blog and Web-SIG.
>
> --
> Gustavo Narea.
> Software Developer.
> 2degrees, Ltd. .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

On 16/06/10 10:48, Graham Dumpleton wrote:
> But that will not happen if you use a different hosting mechanism.
> Thus you end up with a fiddle as documented in:
>
>   http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi
>
> The point I am making is that these hosting system specific fiddles
> should never need to be done by a user.
>   

Right, I see your point.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Jacob Kaplan-Moss wrote:

I couldn't tell from my quick play, though, if there were any
backwards-incompatible changes. There's a fair bit of code churn (in a
good way :), so before we could merge this I'd like a sense of what
any backwards-compatibily concerns would be.


There are some backwards-compatibility issues. I'm currently preparing a 
guide to migrate from the old formtools.wizard to django-formwizard. This 
example will hopefully make the changes clear and migration simple.


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Harro wrote:

We had a site where we needed a wizard with the ability to go back and
forward and store files.
Only allowing files in the last step really isn't an option imho, that
just avoiding the problem ;-)


I totally agree. But it is _one_ option to get around the problem.


What we did was simply store the files in a temporary folder and have
a management command to clean them up when needed. (The files where
stores with a timestamp in the name so we knew when they where old).


Basicly I like this idea. But this is a design decision - how to get rid of 
old files. Going this way, there is also a risk to get dos'ed by bot which 
upload tons of files. If the bots are fast enough, your disk get out of 
space quickly.


I also thought about extending the cleanup-management command, which - atm - 
only removes old/expired sessions. Maybe this could get extended to also 
remove files which a prefix of the session id or something like that.


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

TiNo wrote:

On Sat, May 29, 2010 at 22:07, Stephan Jäkel mailto:m...@sjaekel.com>> wrote:

I already discussed this ticket with Jannis during the sprints and
hope to start a discussion here to find the right way to allow file
uploads and see if my approach takes the right direction.


Couldn't you just use python's /tempfile.NamedTemporaryFile/[1]? That
way the file will get cleaned by the filesystem itself, unless you move
it somewhere else in your ``done`` method. If you pass delete=False, you
will be able to open the file again in the last step, as long as you
properly closed it before.


Could work but going this way, we cannot control how long the file will 
exist (I most ways it has to be there until the session is expired).


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Harro wrote:

+1 on the storage backend. Can the current filestorage backend be
reused for this?


I think yes, but will need some extensions for invalidation of files. But 
can be subclassed (already wrote a experimental backend for doing this)


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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.

Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

I know that queryset.update does not call .save() for each instance and
I know why. I even agree with it :)

However, I'd like to have a bit more control over what update() does,
e.g. for auditing purposes. I know that I can simply write a few lines
of code near every update() call to do what I want, but that violates
DRY.

I have created ticket #13021[1] and created a github branch[2] that
provides the following:

* Two new signals: pre_update and post_update
  The argument for these signals is the queryset and a dict of all 
  changes that will be or have been applied to the objects in that set.

* An update() method for Model.
  This method is a classmethod because it does not deal with instances 
  but querysets. It calls pre_update on all of its fields.

* A pre_update method for Field that does nothing
  Simply exists so that it doesn't have to be checked for

* A pre_update method for DateField for auto_now magic
  This method adds an update for the relevant field to the dict of 
  updates. This means that auto_now really is auto_now, also when 
  using update()

* A patched QuerySet.update() to use the above features.
  - It sends the pre_update and post_update signals
  - It calls the models update method to update the kwargs dict

* Tests and documentation for these features

I've sent this proposal a few months ago and have kept the patch up to
date since. It still applies (I've just rebased it to trunk) and the
tests still pass.

Thanks in advance for considering and commenting,

[1] http://code.djangoproject.com/ticket/13021
[2] http://github.com/seveas/django/tree/seveas/ticket13021

-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: ModelForms and ForeignKeys causing ValueError

[Peter Bengtsson]

Submitted here: http://code.djangoproject.com/ticket/13776

On Jun 14, 2:05 pm, Karen Tracey  wrote:
> On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson  wrote:
> > I'm happy to submit a ticket but wanted to check first that I'm doing
> > the right thing. I think this used to work in Django 1.1 but not now
> > in trunk.
>
> > I can better explain it with code:
>
> > [snip details]
> > The point of this is that I can make an advanced search form where the
> > form is just like the form for added one of these models. In my view I
> > never call the save() method of the form instance.
>
> > # tests.py
> > class SimpleTest(TestCase):
> >    def test_model_forms(self):
> >        from forms import FooBarForm
> >        post = {'name':'Peter'}
> >        f2 = FooBarForm(data=post)
> >        self.assertTrue(not f2.is_valid())
>
> > Instead of returning False on the is_valid() function, it raises a
> > ValueError which looks like this:
>
> > [snip details]
>
> > I can understand that the field doesn't like having None set as a
> > value because it will never allow the save but I'm not interested in
> > saving here. I'm interested in getting a form that models (no pun
> > intended) itself on a model.
>
> > So, bug or feature?
>
> Looks like a bug to me. is_valid() ought not be raising a ValueError...worst
> case it should return False. But in this case True would seem to be the
> correct answer, since you've set the field to not required.
>
> Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Ben Firshman]

On 16 Jun 2010, at 08:24, daonb wrote:
> 
> As I see it, if we're cloning the view, it should be encouraged. I
> forked Ben's code and refactored it so that instead of having the
> methods pass 'request' around, use self.request. I believe it made the
> generic views more readable and it will help users' make their views
> cleaner. My fork is at http://github.com/daonb/django-class-based-views

The request is passed round so methods look like views to decorators. Magically 
dropping it for decorators seems a bit scary. :/

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

[Peter Bengtsson]

I have a modelform where I change the cleaned_data dict after I have
run is_valid() and I'm not sure if this is the totally wrong way of
doing things or if it's a bug.
My code broke when I upgraded to 1.2 so it did work back in the 1.1
days.

# models.py
class Person(models.Model):
name = models.CharField()
age = models.IntegerField()
...

# forms.py
class PersonForm(forms.ModelForm):
class Meta:
model = Person

# views.py

form = PersonForm(data=request.POST)
form.fields['age'].required = False

if form.is_valid():
if not form.cleaned_data['age']:
form.cleaned_data['age'] =
_fetch_age_by_name(form.cleaned_data['name'])
assert form.cleaned_data['age']
person = form.save()   # FAILS!

Trying to run this fails with an IntegrityError or whatever it was
called because it can't save the form when the age field's valid is
None even though I have corrected the form data.

It smells to me like modelforminstance.save() needs to reconstruct the
instance from the cleaned_data again before committing.


PS. The temporary solution for other people getting stuck on this is
the following:

person = form.save(commit=False)
person.age = form.cleaned_data['age']
person.save()



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

[George Sakkis]

On Jun 16, 4:22 pm, Peter Bengtsson  wrote:

> I have a modelform where I change the cleaned_data dict after I have
> run is_valid() and I'm not sure if this is the totally wrong way of
> doing things or if it's a bug.
> My code broke when I upgraded to 1.2 so it did work back in the 1.1
> days.
>
> # models.py
> class Person(models.Model):
> name = models.CharField()
> age = models.IntegerField()
> ...
>
> # forms.py
> class PersonForm(forms.ModelForm):
> class Meta:
> model = Person
>
> # views.py
>
> form = PersonForm(data=request.POST)
> form.fields['age'].required = False
>
> if form.is_valid():
> if not form.cleaned_data['age']:
> form.cleaned_data['age'] =
> _fetch_age_by_name(form.cleaned_data['name'])
> assert form.cleaned_data['age']
> person = form.save()   # FAILS!

Not sure why this fails but regardless, it's not good to have part of
the validation logic outside the form. Instead define a clean() method
in the form, move there the "if not ..." part and check if it also
happens to solve the problem.

By the way, the django-users group is more appropriate for questions
about using Django, as opposed to developing Django itself.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

[Peter Bengtsson]

On 16 June 2010 13:53, George Sakkis  wrote:
> On Jun 16, 4:22 pm, Peter Bengtsson  wrote:
>
>> I have a modelform where I change the cleaned_data dict after I have
>> run is_valid() and I'm not sure if this is the totally wrong way of
>> doing things or if it's a bug.
>> My code broke when I upgraded to 1.2 so it did work back in the 1.1
>> days.
>>
>> # models.py
>> class Person(models.Model):
>>     name = models.CharField()
>>     age = models.IntegerField()
>>     ...
>>
>> # forms.py
>> class PersonForm(forms.ModelForm):
>>     class Meta:
>>         model = Person
>>
>> # views.py
>>
>> form = PersonForm(data=request.POST)
>> form.fields['age'].required = False
>>
>> if form.is_valid():
>>     if not form.cleaned_data['age']:
>>         form.cleaned_data['age'] =
>> _fetch_age_by_name(form.cleaned_data['name'])
>>     assert form.cleaned_data['age']
>>     person = form.save()   # FAILS!
>
> Not sure why this fails but regardless, it's not good to have part of
> the validation logic outside the form. Instead define a clean() method
> in the form, move there the "if not ..." part and check if it also
> happens to solve the problem.
>

That' why I used django-developers instead of django-users. Perhaps
it's a bug and not a "user error".
This functionality has changed in 1.2 so it's not solid what should work how.



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
fun crosstips.org

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Zachary Voase]

Just wanted to add my $0.02; I’ve created a class-based views system
for Django, which you can find at http://github.com/zacharyvoase/django-clsview
(skip down to 'Examples' to see it in action).

It solves the thread-safety problem, decoration is easy, pointing to
views from the URLconf is trivial, and the doctests are pretty
extensive.

The downside (from what I’ve found so far) is that explaining how it
works, or doing advanced hacking on it, requires a pretty thorough
understanding of the Python object model.

Let me know what you think. FWIW, the source code is in the public
domain.

-- Z

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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] Query Refactor Update

[Alex Gaynor]

Hey all,

Another week's gone by (and remarkably quickly if I do say so myself).
 Since last we spoke I've gotten updates to work, basic filters,
cleaned up some fun messes in the source code, added support for
count(), tests for ForeignKeys, and began investigating more complex
lookup types.  Here we come into the issues I've spoken about earlier.
 Given:

class Group(models.Model):
id = models.NativeAutoField(primary_key=True)
name = models.CharField(max_length=255)
year_formed = models.IntegerField(null=True)

and the query:

Group.objects.exclude(year_formed=1972)

we get the SQL:

SELECT "mongodb_group"."id",
   "mongodb_group"."name",
   "mongodb_group"."year_formed"
FROM "mongodb_group"
WHERE NOT (("mongodb_group"."year_formed" = 1972
AND NOT ("mongodb_group"."year_formed" IS NULL)))


Not surprising, however the issue is that the IS NULL where clause
gets deep inside the WHERE tree at exclude() time, and MongoDB has no
use for this clause, it has a different semantic for equality with
None.  I'll be investigating sane solutions to this issue in the
coming week, as well as an issue with Aggregates (aggregates are
converted into their backend specific type eagerly, rather than
lazily).

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
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[daonb]

On Jun 16, 4:45 pm, Ben Firshman  wrote:
>
> The request is passed round so methods look like views to decorators. 
> Magically dropping it for decorators seems a bit scary. :/
>

The way I see it a good framework need to establish a clear contract
with its user. In our case, Django publishes a contract ensuring the
user that when he inherits from View and overrides any of: GET, POST,
UPDATE, DELETE,get_response, get_content, get_resource, render_html,
get_template, get_context and a few others, the request attribute of
self is current.

I agree stripping the request looks a bit scary, but at least it's
only 5 lines of simple code:-). They way I see it,  decorators are
global so they need the request and Django adds it for them. When the
global decorators are done, Django can strip the request and get the
user to trust our contract.

Benny.






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Class based generic views in 1.3?

[Nick Fitzgerald]

I have forked bfirsh's code as well on github:
http://github.com/fitzgen/django-class-based-views

I have changed the code
to use __new__ rather than copying self. I have also merged in daonb's
commit to make request implicit to all methods via self.request.

All feedback is very welcome! :)

_Nick_



On Wed, Jun 16, 2010 at 4:14 PM, daonb  wrote:

> On Jun 16, 4:45 pm, Ben Firshman  wrote:
> >
> > The request is passed round so methods look like views to decorators.
> Magically dropping it for decorators seems a bit scary. :/
> >
>
> The way I see it a good framework need to establish a clear contract
> with its user. In our case, Django publishes a contract ensuring the
> user that when he inherits from View and overrides any of: GET, POST,
> UPDATE, DELETE,get_response, get_content, get_resource, render_html,
> get_template, get_context and a few others, the request attribute of
> self is current.
>
> I agree stripping the request looks a bit scary, but at least it's
> only 5 lines of simple code:-). They way I see it,  decorators are
> global so they need the request and Django adds it for them. When the
> global decorators are done, Django can strip the request and get the
> user to trust our contract.
>
> Benny.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Alex Gaynor wrote:

My one comment (and we discussed this on IRC) is that this really
should inherit from GenericView IMO, so it'd be nice if that landed
before this.


Agreed, many stuff in formwizard/classbased-views is duplicated. (I actually 
got the thread-safety bit from there).


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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.