Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

[Luc Saffre]

Thank you, Tamas. Yes, that's what I mean. Without you I might have come
to believe that something is wrong with my brain...

And yes, I can live with it. It's just a pity that others will stumble
on it just because it isn't documented.

Luc

On 10.02.2010 19:30, Tamas Szabo wrote:
> Hi,
> 
> Well, I'm not a django core developer, so my post probably won't weight
> that much, but I can't leave Luc with the feeling that that aren't other
> people that have the same opinion as him.
> Luc, I'm with you on this one :)
> 
> First of all the problem is in an area of handling the mismatches
> between the OO and the relational models, an area that should always
> cause discussions. So, Luc I guess you have to accept that this is a
> gray area and this is how Django's ORM works. Life goes on ...
> 
> On the other hand, I do not understand how you can't see the point that
> Luc is making and how can you say that this makes sense from both the ER
> and ORM point of view. When you are working with your OO model the
> relationship between your models aren't represented by FK pointers. They
> should map to attributes of models or collections of models.
> FK based relations from the DB are represented by attributes and
> collections in the OO world and the ORM should take care of this mapping
> and making it transparent.
> 
> In an ideal world you shouldn't use or even know about those _id fields
> when working with your OO models.
> Your working with your OO domain model that consists of Python classes
> and they should work like any other normal Python classes until you use
> save or load them (then the ORM kicks in and does the mapping).
> But until you do that, they should behave like Python classes so
> throwing DoesNotExist Exception when you access an attribute of a class
> feels a little bit strange.
> 
> But of course our world is more pragmatic and I can live with the
> current implementation (and I hope Luc can do the same), but I can
> certainly understand why it feels strange to him and why he resists
> using _id fields while working with his models.
> 
> All The Best,
> 
> Tamas
> 

-- 
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: QuerySet.exists() - Possible bug?

[David Cramer]

MySQL, in this situation, would have to actually select a row to
return a result, so it's slower. If it was just select 1 as a from
table where indexed_value = N, it doesn't even hit the tables, just
the indexes.

It's definitely not more efficient, and probably just an oversight
somewhere.

On Feb 10, 7:35 am, Jeremy Dunck  wrote:
> On Wed, Feb 10, 2010 at 2:05 AM, Karen Tracey  wrote:
>
> ...
>
> >>  * What version of Django (including SVN revision, if appropriate) are
> >> you using?
>
> > I tried current trunk and backed off to the changeset where the function was
> > added -- query was the same.  Looking at the idiom it replaced, the extra
> > select of the constant 1 value as 'a' was followed by a values('a') that
> > turned the result into a ValuesQuerySet. I don't see where this is being
> > done with the exists() implementation. As a result it seems to be a regular
> > QuerySet with a query with default_cols=True, resulting in all the default
> > columns getting pulled into the query.
>
> It seems odd to me that adding columns to the result of a returned row
> would be significantly slower than the PK.  It also seems to me that
> using the default ordering might be unnecessary overhead, too.
>
> But I wonder if different DBs return different things based on the
> columns in the select clause?  Perhaps Malcolm had a reason for making
> the change.  :-/

-- 
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: Bug in Form metaclass?

[Simon Meers]

Thanks for looking into this Russ

> Firstly, django-dev isn't "second tier tech support" - if you don't
> get an answer on django-users for a user-space question, that's a
> pity, but it doesn't mean you can or should "escalate" to django-dev.

I realise this; I thought this was the place to discuss potential
bugs, but thought I'd better throw some sanity checks out elsewhere
before I did.

> Doesn't look like a bug. Subclassing AuthenticationForm works for me,
> and I can't find any way to make your test case fail in the way you
> describe.

I thought I was going crazy when I tried again just now and couldn't
reproduce it myself! Thankfully I tracked the problem down to
importing django via a symlink in the project directory to the
appropriate version. If I remove the symlink and let it import django
from elsewhere in the pythonpath, it works as expected.

$ cat test.py
from django.contrib.auth.forms import AuthenticationForm
from django import forms

class MyForm(AuthenticationForm):
extra_field = forms.BooleanField()

print MyForm().fields.keys()
$ ./manage.py validate
['username', 'password', 'extra_field']
0 errors found
$ ln -s /media/d/Development/django/django-trunk/django/
$ ./manage.py validate
['username', 'password']
0 errors found

Odd. I've never encountered any other problems when using a local
symlink to django; everything else seems to operate fine.

-- 
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: Translation policy - clarification required?

[Russell Keith-Magee]

On Thu, Feb 11, 2010 at 8:10 AM, Alex Gaynor  wrote:
> On Wed, Feb 10, 2010 at 7:07 PM, Russell Keith-Magee
>  wrote:
>> Hi all,
>>
>> I need some feedback/assistance from those with experience with the
>> translation tool set.
>>
>> Karen Tracey just pointed out that I may have made a booboo with the
>> handling of translations in the 1.1.X branch.
>>
>> I committed updates to trunk for the no, fr, nl, sk, cz and ro
>> translations. I also added two new stub translations: bn, fr-nl.
>>
>> I then proceeded to backport those translations to the 1.1.X branch.
>> The merge didn't raise any conflicts, but looking at the diffs, the
>> changes are mostly line number changes, not new content (although
>> there are a couple of translation changes and additions).
>>
>> This got noticed because I then *didn't* backport r12348, where I
>> updated the ga translation. As I recall, the merge wasn't clean.
>>
>> So, I need some advice from people that are more familiar with the i18n 
>> tools:
>>
>> Have I messed up here?
>>
>> Is a "backport if it merges cleanly" a reasonable approach? Or have I
>> made life more difficult for anyone trying to do a 1.1.X translation?
>>
>> Should I revert the translation updates for the 1.1.X branch?
>>
>> Are the rules the same for a completely new translation as for an
>> updated translation?
>>
>> FYI:  The affected revisions are 12325-12332, plus 12334.
>
> I'm not an expert here, but I recall Malcolm saying that it was his
> policy not to do backports of translation committs.

Jannis pointed me to this thead [1] from Malcolm, confirming this.

The question now becomes "should I revert those changesets?"

[1] 
http://groups.google.com/group/django-i18n/browse_thread/thread/c3547e3f082ac1e7

Russ %-)

-- 
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: Bug in Form metaclass?

[Russell Keith-Magee]

On Thu, Feb 11, 2010 at 7:40 AM, Simon Meers  wrote:
> Disclaimer: Just in case this was a naive mistake on my part, I posted
> this on django-users first [1] and posed the question several times on
> #django, but have received no answers.

Firstly, django-dev isn't "second tier tech support" - if you don't
get an answer on django-users for a user-space question, that's a
pity, but it doesn't mean you can or should "escalate" to django-dev.

That said:

> Is this a bug? The same happens if you try to import, say,
> django.contrib.auth.forms.AuthenticationForm and subclass it. Surely
> I'm missing something here?

Doesn't look like a bug. Subclassing AuthenticationForm works for me,
and I can't find any way to make your test case fail in the way you
describe.

Yours,
Russ Magee %-)

-- 
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: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Russell Keith-Magee]

On Wed, Feb 10, 2010 at 11:09 PM, Jari Pennanen  wrote:
> Hi!
>
> I was wondering what is the status of branch branches/soc2009/http-
> wsgi-improvements ( 
> http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> )? I'm personally interested one bug it fixes, mainly ticket #2131
> ( http://code.djangoproject.com/ticket/2131 )
>
> The branch seems to be 6 months old, and this makes me nervous to rely
> on it, if it is not merged to trunk I'm screwed on relying on branch
> that old...

We're in an unfortunate situation here. The person who mentored that
project (Malcolm) hasn't had the spare time to contribute to Django to
see the fruits of that branch delivered to trunk.

At this point, I wouldn't be relying on the branch - it's not
receiving any specific attention, and it's not (to the best of my
knowledge) in a ready-to-merge state.

Yours,
Russ Magee %-)

-- 
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: Translation policy - clarification required?

[Alex Gaynor]

On Wed, Feb 10, 2010 at 7:07 PM, Russell Keith-Magee
 wrote:
> Hi all,
>
> I need some feedback/assistance from those with experience with the
> translation tool set.
>
> Karen Tracey just pointed out that I may have made a booboo with the
> handling of translations in the 1.1.X branch.
>
> I committed updates to trunk for the no, fr, nl, sk, cz and ro
> translations. I also added two new stub translations: bn, fr-nl.
>
> I then proceeded to backport those translations to the 1.1.X branch.
> The merge didn't raise any conflicts, but looking at the diffs, the
> changes are mostly line number changes, not new content (although
> there are a couple of translation changes and additions).
>
> This got noticed because I then *didn't* backport r12348, where I
> updated the ga translation. As I recall, the merge wasn't clean.
>
> So, I need some advice from people that are more familiar with the i18n tools:
>
> Have I messed up here?
>
> Is a "backport if it merges cleanly" a reasonable approach? Or have I
> made life more difficult for anyone trying to do a 1.1.X translation?
>
> Should I revert the translation updates for the 1.1.X branch?
>
> Are the rules the same for a completely new translation as for an
> updated translation?
>
> FYI:  The affected revisions are 12325-12332, plus 12334.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
>
>

I'm not an expert here, but I recall Malcolm saying that it was his
policy not to do backports of translation committs.

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.

Translation policy - clarification required?

[Russell Keith-Magee]

Hi all,

I need some feedback/assistance from those with experience with the
translation tool set.

Karen Tracey just pointed out that I may have made a booboo with the
handling of translations in the 1.1.X branch.

I committed updates to trunk for the no, fr, nl, sk, cz and ro
translations. I also added two new stub translations: bn, fr-nl.

I then proceeded to backport those translations to the 1.1.X branch.
The merge didn't raise any conflicts, but looking at the diffs, the
changes are mostly line number changes, not new content (although
there are a couple of translation changes and additions).

This got noticed because I then *didn't* backport r12348, where I
updated the ga translation. As I recall, the merge wasn't clean.

So, I need some advice from people that are more familiar with the i18n tools:

Have I messed up here?

Is a "backport if it merges cleanly" a reasonable approach? Or have I
made life more difficult for anyone trying to do a 1.1.X translation?

Should I revert the translation updates for the 1.1.X branch?

Are the rules the same for a completely new translation as for an
updated translation?

FYI:  The affected revisions are 12325-12332, plus 12334.

Yours,
Russ Magee %-)

-- 
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: What The Enterprise wants from Django

[Luc Saffre]

On 19.01.2010 23:26, Jacob Kaplan-Moss wrote:
> Finally, we ruminated over the difficulties in building rich internet
> applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine,
> but we doesn't really have a good answer for the people who want
> something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting
> all sorts of marketing dollars into Flex/Silverlight, and although
> HTML5 can do some amazing things, the lack of tooling is a big danger.
> (I've written at more length about this in the past:
> http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications).

It's a bit early to speak about Lino, but Jacob's post incited me to
write a kind of preview for Django developers:

http://code.google.com/p/lino/wiki/LinoAndDjango

Encouraging words are welcome now, but wait a few months before you
seriously investigate this project.

Luc

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

Bug in Form metaclass?

[Simon Meers]

Disclaimer: Just in case this was a naive mistake on my part, I posted
this on django-users first [1] and posed the question several times on
#django, but have received no answers.

#
# forms.py:
#
    from django import forms
    class TestForm(forms.Form):
        test_field = forms.BooleanField()
#

#
# test.py:
#
    # import the same class from two different locations:
    from project_name.forms import TestForm
    from project_name.some_module.forms import TestForm as TestForm2

    class MyForm(TestForm):
        extra_field = forms.BooleanField()

    print MyForm().fields.keys()
    # prints: ['test_field', 'extra_field'] as expected

    class MyForm2(TestForm2):
        extra_field = forms.BooleanField()

    print MyForm2().fields.keys()
    # prints: ['test_field']
    # extra fields not registered if superclass imported from other app/module!
#

Python 2.6.4, Django SVN-12401

Is this a bug? The same happens if you try to import, say,
django.contrib.auth.forms.AuthenticationForm and subclass it. Surely
I'm missing something here?

Simon

[1] 
http://groups.google.com/group/django-users/browse_thread/thread/b4b4ddd684b352e1

-- 
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: Add Mod(%) Operator to If Tag

[Luke Plant]

On Wednesday 10 February 2010 19:00:47 Jonas Obrist wrote:

> I'm not sure if this was discussed before, but what about allowing
>  to easily register custom comparison operators? I'm thinking of a
>  similar API we currently have for registering template
>  tags/filters for if-tag operators.

My gut instinct is this would be a very bad idea for readability.  
Defining new operators works OK in a language like Haskell (and even 
there it can be pretty confusing), but in a template language...?

Luke

-- 
You meet a lot of smart guys with stupid wives, but you almost 
never meet a smart woman with a stupid husband. (Erica Jong)

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-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: contrib.Auth

[Sayane]

I think that an easy way to define your own user model is better idea. Auth
app should be more generic. It should define a protocol for user, group and
permission objects (and of course there should be back compatible
implementation of this protocols used by default). There is a ticket about
extending auth app: http://code.djangoproject.com/ticket/3011, but I think
this could be done in a better way.

Sorry for my english :-)

2010/2/10 Harro 

> Good suggestions, I think removing username and email from the user
> might be a good idea.
> Right now I authenticate with the email address stored on the profile
> and the username is a random hash :)
>
> As for breaking data and migrations; it shouldn't be that hard to
> write a management command that does this.
>
>
> On Feb 9, 5:54 pm, Vitaly Babiy  wrote:
> > Vitaly Babiy
> >
> > On Tue, Feb 9, 2010 at 3:16 AM, James Bennett 
> wrote:
> > > On Tue, Feb 9, 2010 at 2:09 AM, Harro  wrote:
> > > > - Make email unique and username non-required on the model. That
> would
> > > > make implementing something that authenticated by email a lot
> > > > easier :)
> >
> > > 1. It's *extremely* unlikely that changes will be considered which
> > > require every Django install on the planet to undergo a DB schema
> > > migration.
> >
> > James this is true. Another reason it would be nice to have a
> > migration framework for Django.
> >
> >
> >
> >
> >
> > > 2. The appropriate time to discuss possible 1.3 features is when the
> > > feature-discussion window for 1.3 comes up. That will happen sometime
> > > in April, probably. Suggestions made now are likely to be forgotten by
> > > the time that happens.
> >
> > > Yeah I plan to bring this up again, around that time frame.
> >
> > > --
> > > "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-develop...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > django-developers+unsubscr...@googlegroups.com i...@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.
>
>

-- 
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: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Forest Bond]

Hi,

On Wed, Feb 10, 2010 at 11:09:29AM -0800, mrts wrote:
> On Feb 10, 5:24 pm, Tom Evans  wrote:
> > On Wed, Feb 10, 2010 at 3:09 PM, Jari Pennanen  
> > wrote:
> > > Hi!
> >
> > > I was wondering what is the status of branch branches/soc2009/http-
> > > wsgi-improvements 
> > > (http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> > > )? I'm personally interested one bug it fixes, mainly ticket #2131
> > > (http://code.djangoproject.com/ticket/2131)
> 
> You don't need that fix to use efficient file serving.
> 
> Just use an empty response and set the X-Sendfile header manually if
> using
> Apache. If not, check your server documentation for the right header
> name.
> 
> E.g.:
> 
> response = HttpResponse()
> response['X-Sendfile'] = '/full/path/to/file'
> response['Content-Type'] = 'some/content_type'
> response['Content-Length'] = os.stat('/full/path/to/file').st_size
> response['Content-Disposition'] = 'attachment; filename="foo"'
> return response

This only works for use cases where you have an on-disk file to serve.  There
are plenty of situations where this may not be the case:

* Cloud storage services (e.g. Rackspace Cloud Files)
* Large data sets (e.g. data exports to CSV, XML)

Etc.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature

Re: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[mrts]

On Feb 10, 5:24 pm, Tom Evans  wrote:
> On Wed, Feb 10, 2010 at 3:09 PM, Jari Pennanen  
> wrote:
> > Hi!
>
> > I was wondering what is the status of branch branches/soc2009/http-
> > wsgi-improvements 
> > (http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> > )? I'm personally interested one bug it fixes, mainly ticket #2131
> > (http://code.djangoproject.com/ticket/2131)

You don't need that fix to use efficient file serving.

Just use an empty response and set the X-Sendfile header manually if
using
Apache. If not, check your server documentation for the right header
name.

E.g.:

response = HttpResponse()
response['X-Sendfile'] = '/full/path/to/file'
response['Content-Type'] = 'some/content_type'
response['Content-Length'] = os.stat('/full/path/to/file').st_size
response['Content-Disposition'] = 'attachment; filename="foo"'
return response

-- 
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: Add Mod(%) Operator to If Tag

[Jonas Obrist]

Alex Gaynor wrote:

On Wed, Feb 10, 2010 at 12:10 PM, megaman821  wrote:
  

Since Django 1.2 is not out yet I have been using the smart_if tag in
all my projects, with one addition. Since I believe the new if tag is
based on the smart_if tag code on Django Snippets, I want to propose
adding the mod(%) operator to it.

Often I have display logic where I am displaying a grid of items so
every nth item I need to create a new row. Right now you can awkwardly
do this with the cycle tag but it gets a bit tedious and error prone
if you want to have a row of 10 items. For example, you could do:

{% cycle '' '' '' '' '' '' '' '' '' '' %}

or

{% if forloop.counter % 10 %}
   
{% endif %}

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





Isn't this solved by the |divisibleby filter?

Alex

  


I'm not sure if this was discussed before, but what about allowing to 
easily register custom comparison operators? I'm thinking of a similar 
API we currently have for registering template tags/filters for if-tag 
operators.


Jonas

--
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: #12801 : Allow empty non-nullable ForeignKey fields until save()

[Tamas Szabo]

Hi,

Well, I'm not a django core developer, so my post probably won't weight that
much, but I can't leave Luc with the feeling that that aren't other people
that have the same opinion as him.
Luc, I'm with you on this one :)

First of all the problem is in an area of handling the mismatches between
the OO and the relational models, an area that should always cause
discussions. So, Luc I guess you have to accept that this is a gray area and
this is how Django's ORM works. Life goes on ...

On the other hand, I do not understand how you can't see the point that Luc
is making and how can you say that this makes sense from both the ER and ORM
point of view. When you are working with your OO model the relationship
between your models aren't represented by FK pointers. They should map to
attributes of models or collections of models.
FK based relations from the DB are represented by attributes and collections
in the OO world and the ORM should take care of this mapping and making it
transparent.

In an ideal world you shouldn't use or even know about those _id fields when
working with your OO models.
Your working with your OO domain model that consists of Python classes and
they should work like any other normal Python classes until you use save or
load them (then the ORM kicks in and does the mapping).
But until you do that, they should behave like Python classes so throwing
DoesNotExist Exception when you access an attribute of a class feels a
little bit strange.

But of course our world is more pragmatic and I can live with the current
implementation (and I hope Luc can do the same), but I can certainly
understand why it feels strange to him and why he resists using _id fields
while working with his models.

All The Best,

Tamas


When you are working with your models

On Wed, Feb 10, 2010 at 10:42 PM, Luc Saffre  wrote:

> Thank you, Henrique, for dropping in.
>
> As I said earlier, I don't want to bother the community with my
> stubbornness or whatever it may be, so feel free to STOP READING HERE if
> there is danger that this topic wastes your time.
>
> But to be honest, I must unfortunately say that I disagree also with
> your explanations and that they (for me) confirmed my opinion.
>
> The expression `a_model.b_related` (where `a_model` is an instance of a
> Model subclass that defines a field `b_related`) must always yield a
> value in the Pythonic meaning (that is, it may yield None which is also
> a value in Python).
>
> This same expression should raise an exception only if the field name is
> wrongly spelled, or if an error occured when constructing the related
> instance to be yielded (e.g. a failed DB lookup in the case of a FK
> field other than None).
>
> A FK containing None (which is already now possible for nullable FK
> fields) will never cause a DB lookup.
>
> Django guarantees that the value of a FK field will always be either
> None or an instance of the related Model.
>
> Django never guaratees that every instance of a Model exists as a row in
> the database.
>
> Django's current behaviour is not correct because it forces me to access
> non-nullable FK fields differently than nullable ones. "In Python,
> throwing exceptions for expected outcomes is considered very bad form"
> [1]. Django should raise an exception only if I try to save an instance
> with invalid data (for example None in a non-nullable FK field), but not
> when I try to access any data, may it be valid or not
>
> [1]
>
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/7d6191ecba652daf
>
> Luc
>
>
> On 10.02.2010 6:28, hcarvalhoalves wrote:
> > Maybe I can help Luc? I had similar questions once, because I started
> > learning Django while deploying with a legacy database.
> >
> > On 8 fev, 20:31, Luc Saffre  wrote:
> >> You cannot ask user code to not even look at invalid data. I'm
> >> not allergic to exceptions, but raising an exception when I ask for the
> >> content of a field is not appropriate behaviour.
> >>
> >> Luc
> >
> > Raising the exception *is* appropriate behaviour, because when you
> > access `a_model.b_related`, and `b_related` is a ForeignKey, you're
> > not really accessing a value, but doing a lookup. This is consistent
> > with both the ER and ORM model, where FK's are pointers, not values.
> > And a FK pointing to a non-existant row *is* an exception. It means
> > broken data.
> >
> > If you want the content of the *field*, what you really should check
> > is `a_model.b_related_id is None`, which is checking if a pointer was
> > set. Still, it doesn't guarantee that this pointer leads to anywhere
> > valid. That's why dealing with the exception is a common idiom, "fail
> > early, fail loudly", and particularly useful in this case to maintain
> > DB consistency.
> >
> > I hope it helps in understanding the rationale behind the behaviour
> > and why Luke marked as invalid.
> >
>
> --
> You received this message because you are subscribed to 

Add Mod(%) Operator to If Tag

[megaman821]

Since Django 1.2 is not out yet I have been using the smart_if tag in
all my projects, with one addition. Since I believe the new if tag is
based on the smart_if tag code on Django Snippets, I want to propose
adding the mod(%) operator to it.

Often I have display logic where I am displaying a grid of items so
every nth item I need to create a new row. Right now you can awkwardly
do this with the cycle tag but it gets a bit tedious and error prone
if you want to have a row of 10 items. For example, you could do:

{% cycle '' '' '' '' '' '' '' '' '' '' %}

or

{% if forloop.counter % 10 %}

{% endif %}

-- 
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: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Tom Evans]

On Wed, Feb 10, 2010 at 3:09 PM, Jari Pennanen  wrote:
> Hi!
>
> I was wondering what is the status of branch branches/soc2009/http-
> wsgi-improvements ( 
> http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> )? I'm personally interested one bug it fixes, mainly ticket #2131
> ( http://code.djangoproject.com/ticket/2131 )
>
> The branch seems to be 6 months old, and this makes me nervous to rely
> on it, if it is not merged to trunk I'm screwed on relying on branch
> that old...
>

This branch also has code on it that breaks iterator based responses.
See my objections to that particular part of the code being merged to
trunk here:

http://code.djangoproject.com/ticket/6527#comment:19

Cheers

Tom

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

Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Jari Pennanen]

Hi!

I was wondering what is the status of branch branches/soc2009/http-
wsgi-improvements ( 
http://github.com/django/django/tree/soc2009/http-wsgi-improvements
)? I'm personally interested one bug it fixes, mainly ticket #2131
( http://code.djangoproject.com/ticket/2131 )

The branch seems to be 6 months old, and this makes me nervous to rely
on it, if it is not merged to trunk I'm screwed on relying on branch
that old...

-- 
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: #12801 : Allow empty non-nullable ForeignKey fields until save()

[Luc Saffre]

Thank you, Henrique, for dropping in.

As I said earlier, I don't want to bother the community with my
stubbornness or whatever it may be, so feel free to STOP READING HERE if
there is danger that this topic wastes your time.

But to be honest, I must unfortunately say that I disagree also with
your explanations and that they (for me) confirmed my opinion.

The expression `a_model.b_related` (where `a_model` is an instance of a
Model subclass that defines a field `b_related`) must always yield a
value in the Pythonic meaning (that is, it may yield None which is also
a value in Python).

This same expression should raise an exception only if the field name is
wrongly spelled, or if an error occured when constructing the related
instance to be yielded (e.g. a failed DB lookup in the case of a FK
field other than None).

A FK containing None (which is already now possible for nullable FK
fields) will never cause a DB lookup.

Django guarantees that the value of a FK field will always be either
None or an instance of the related Model.

Django never guaratees that every instance of a Model exists as a row in
the database.

Django's current behaviour is not correct because it forces me to access
non-nullable FK fields differently than nullable ones. "In Python,
throwing exceptions for expected outcomes is considered very bad form"
[1]. Django should raise an exception only if I try to save an instance
with invalid data (for example None in a non-nullable FK field), but not
when I try to access any data, may it be valid or not

[1]
http://groups.google.com/group/comp.lang.python/browse_thread/thread/7d6191ecba652daf

Luc


On 10.02.2010 6:28, hcarvalhoalves wrote:
> Maybe I can help Luc? I had similar questions once, because I started
> learning Django while deploying with a legacy database.
> 
> On 8 fev, 20:31, Luc Saffre  wrote:
>> You cannot ask user code to not even look at invalid data. I'm
>> not allergic to exceptions, but raising an exception when I ask for the
>> content of a field is not appropriate behaviour.
>>
>> Luc
> 
> Raising the exception *is* appropriate behaviour, because when you
> access `a_model.b_related`, and `b_related` is a ForeignKey, you're
> not really accessing a value, but doing a lookup. This is consistent
> with both the ER and ORM model, where FK's are pointers, not values.
> And a FK pointing to a non-existant row *is* an exception. It means
> broken data.
> 
> If you want the content of the *field*, what you really should check
> is `a_model.b_related_id is None`, which is checking if a pointer was
> set. Still, it doesn't guarantee that this pointer leads to anywhere
> valid. That's why dealing with the exception is a common idiom, "fail
> early, fail loudly", and particularly useful in this case to maintain
> DB consistency.
> 
> I hope it helps in understanding the rationale behind the behaviour
> and why Luke marked as invalid.
> 

-- 
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: QuerySet.exists() - Possible bug?

[Jeremy Dunck]

On Wed, Feb 10, 2010 at 2:05 AM, Karen Tracey  wrote:
...
>>  * What version of Django (including SVN revision, if appropriate) are
>> you using?
>
> I tried current trunk and backed off to the changeset where the function was
> added -- query was the same.  Looking at the idiom it replaced, the extra
> select of the constant 1 value as 'a' was followed by a values('a') that
> turned the result into a ValuesQuerySet. I don't see where this is being
> done with the exists() implementation. As a result it seems to be a regular
> QuerySet with a query with default_cols=True, resulting in all the default
> columns getting pulled into the query.

It seems odd to me that adding columns to the result of a returned row
would be significantly slower than the PK.  It also seems to me that
using the default ordering might be unnecessary overhead, too.

But I wonder if different DBs return different things based on the
columns in the select clause?  Perhaps Malcolm had a reason for making
the change.  :-/

-- 
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: #12801 : Allow empty non-nullable ForeignKey fields until save()

[Luc Saffre]

Thanks, Karen, for your explanations which are very clear. I accept the
community's decision and won't bother you any longer. And maybe one day
I will even understand why this behaviour is not odd.

Luc

On 9.02.2010 17:03, Karen Tracey wrote:
> On Tue, Feb 9, 2010 at 3:02 AM, Luc Saffre  > wrote:
> 
> "Closed" as "Invalid", as I understand it, means that this ticket is not
> worth to get more consideration and that further comments are not
> welcome.
> 
> "Open" with a triage stage of "Someday/Maybe" would help people who
> stumble on this behaviour to find our discussion. Especially if we add a
> link to this discussion thread.
> 
> 
> Open with a triage state of Someday/Maybe would imply that the current
> behavior has been acknowledged as wrong and that a change in the
> behavior might be expected. It would also imply that if someone provided
> a patch to change the behavior, it would have a chance of getting
> checked in. With two core devs stating they see the current behavior as
> logical and consistent and none stepping up to say the opposite, a
> change in behavior here isn't going to happen. Thus an open state for
> this ticket would give people the wrong impression of the state of the
> issue. 
> 
> Closed tickets are as easily found as open ones -- anyone doing research
> in an attempt to understand current behavior should not be limiting
> their searches to only open tickets.
> 
> The right state for this ticket is closed, which means it's been
> reviewed and determined that the current behavior is correct and nothing
> needs to be done to fix it. I would not term further comemnts
> "unwelcome", but they are not particularly useful unless someone has
> some new light to shed on the issue.
> 
> 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.

-- 
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: Admin refactoring

[Russell Keith-Magee]

On Wed, Feb 10, 2010 at 6:41 PM, PauloS  wrote:
> Currently it is easy to change the template engine in a Django
> project, but if you change the ORM layer you lost the whole Admin
> thing, the very app that made Django so special.
>
> If we are talking about refactoring Admin code (not only html/css
> stuff), do you guys think it can be more decoupled from Django ORM?
>
> Is it possible to design some abstraction middleware to loose the bond
> between admin and Django ORM?

Is it possible - almost certainly. After all, you can do anything if
you write enough code.

However, it's not going to be easy. Django's Admin works by exploiting
metadata that the ORM provides. Replacing that metadata source is not
going to be a trivial activity.

If you want this, *you're* going to have to investigate what changes
are required.

Proposing that Django adopt a complex abstraction layer to keep from
using it's own internal facilities is going to be a hard sell. An
approach more likely to succeed is an abstraction layer that lets
MyFavouriteORM look like enough like Django's ORM to fool the Admin.
Such a tool wouldn't even need to live in Django's core - it could
easily live as an external project.

So - in summary: It's possibly possible. You're going to have to do
the heavy lifting to find out the details. If you can make a concrete
proposal that doesn't involve completely rearchitecting Django, we'll
consider it.

Yours,
Russ Magee %-)

-- 
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: Admin refactoring

[Richard Laager]

On Wed, 2010-02-10 at 02:41 -0800, PauloS wrote:
> If we are talking about refactoring Admin code (not only html/css
> stuff), do you guys think it can be more decoupled from Django ORM?

How so?

> Is it possible to design some abstraction middleware to loose the bond
> between admin and Django ORM?

To what end?

What are you trying to accomplish?

Richard


signature.asc
Description: This is a digitally signed message part

Admin refactoring

[PauloS]

Currently it is easy to change the template engine in a Django
project, but if you change the ORM layer you lost the whole Admin
thing, the very app that made Django so special.

If we are talking about refactoring Admin code (not only html/css
stuff), do you guys think it can be more decoupled from Django ORM?

Is it possible to design some abstraction middleware to loose the bond
between admin and Django ORM?

Regards,
--
Paulo

-- 
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: contrib.Auth

[Harro]

Good suggestions, I think removing username and email from the user
might be a good idea.
Right now I authenticate with the email address stored on the profile
and the username is a random hash :)

As for breaking data and migrations; it shouldn't be that hard to
write a management command that does this.


On Feb 9, 5:54 pm, Vitaly Babiy  wrote:
> Vitaly Babiy
>
> On Tue, Feb 9, 2010 at 3:16 AM, James Bennett  wrote:
> > On Tue, Feb 9, 2010 at 2:09 AM, Harro  wrote:
> > > - Make email unique and username non-required on the model. That would
> > > make implementing something that authenticated by email a lot
> > > easier :)
>
> > 1. It's *extremely* unlikely that changes will be considered which
> > require every Django install on the planet to undergo a DB schema
> > migration.
>
> James this is true. Another reason it would be nice to have a
> migration framework for Django.
>
>
>
>
>
> > 2. The appropriate time to discuss possible 1.3 features is when the
> > feature-discussion window for 1.3 comes up. That will happen sometime
> > in April, probably. Suggestions made now are likely to be forgotten by
> > the time that happens.
>
> > Yeah I plan to bring this up again, around that time frame.
>
> > --
> > "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-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com > i...@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: QuerySet.exists() - Possible bug?

[Karen Tracey]

On Wed, Feb 10, 2010 at 2:22 AM, Russell Keith-Magee  wrote:

> It certainly doesn't look right; .exists() should be faster than
> .count(), and having all the extra columns in the query looks a little
> weird.
>
> However, to say for sure, we need a few more details:
>
>  * Does this only happen when using David's devserver, or does it
> happen in a normal Django shell?
>
>
I can recreate with just simple shell queries and checking the sql in
django.db.connection


>  * Can you give a *specific* example of a model and query that is
> causing this? Or, if it's happening in the process of running a
> management command or other Django-internal activity, what do you need
> to do to stimulate the problem?
>

Every exists() query I tried shows this behavior.  For example:

>>> from django.contrib.auth.models import User
>>> User.objects.filter(username='kmt').exists()
True
>>> from django.db import connection
>>> connection.queries[-1]
{'time': '0.001', 'sql': u'SELECT (1) AS `a`, `auth_user`.`id`,
`auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`,
`auth_user`.`email`, `auth_user`.`password`, `auth_user`.`is_staff`,
`auth_user`.`is_active`, `auth_user`.`is_superuser`,
`auth_user`.`last_login`, `auth_user`.`date_joined` FROM `auth_user` WHERE
`auth_user`.`username` = kmt '}
>>>


>
>  * Are you doing anything interesting with select_related() or
> anything like that?
>
>
No.


>  * What version of Django (including SVN revision, if appropriate) are
> you using?
>

I tried current trunk and backed off to the changeset where the function was
added -- query was the same.  Looking at the idiom it replaced, the extra
select of the constant 1 value as 'a' was followed by a values('a') that
turned the result into a ValuesQuerySet. I don't see where this is being
done with the exists() implementation. As a result it seems to be a regular
QuerySet with a query with default_cols=True, resulting in all the default
columns getting pulled into the query.

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.