On returning appropriate subclass instances when querying a model with subclasses

[Andrea Zilio]

Hi all,

Here's what I'm talking about:
You have 3 models: Place, Restaurant and Cinema where Restaurant and
Cinema both inherits from Place.
So in the database you have some simple places, some places which
really are Cinemas and some places which really are Restaurants.

Well, I think that this should be possible:
>>> Place.objects.all()
[, , , ]
(Current implementation only returns Places objects)

This seems to have been taken into account here:
http://code.djangoproject.com/wiki/ModelInheritance#a2.ModelingjoinsinSQL
In that wiki page it's said that this should be possible using LEFT
JOINS, but that this approach could drive to a lot of overhead as the
subclass count increase.

But... What about allowing this kind of query-including-subclasses by
requesting it in an explicit way?
Something like this?
>>> Place.objects.select_subclasses(Cinema,Restaurant).all()
[, , , ]
>>> Place.objects.select_subclasses(Cinema).all()   # Here we ask to join ONLY 
>>> with Cinema
[, , , ]

Maybe this has been previously discussed but I couldn't find any
ticket or any discussion about it.
So take this as a proposal if it wasn't already discussed or as a
request to have some info about the previous discussion.

Thanks in advance

P.S.
SqlObject seems to have implemented something like this
http://www.sqlobject.org/Inheritance.html

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Dave Jeffery]

On Fri, Aug 21, 2009 at 4:10 PM, Dave Jeffery  wrote:

>
> Does anybody have a copy (or know where I could a copy) of the completed
> code for the Django tutorial?
>

Ok, I quickly ran through the tutorial steps, here is what the code was
looking like at the end of the current tutorials:
http://files.davejeffery.com/django/polls.zip

Hope this helps anybody else who wants to add more steps to the tutorial.

--~--~-~--~~~---~--~~
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: Request for comments on patch

[Russell Keith-Magee]

On Sat, Aug 22, 2009 at 9:14 PM, Manoj  Govindan wrote:
>
> I recently came across a django ticket dealing with a pet issue of
> mine. I thought of expediting the chances of a fix by writing up a
> patch myself.
>
> Ticket: http://code.djangoproject.com/ticket/5416
>
> I would like to know what experienced developers think of the patch.
> Be kind, I am a newbie ;)

I've just left a comment on the ticket.

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

Request for comments on patch

[Manoj Govindan]

I recently came across a django ticket dealing with a pet issue of
mine. I thought of expediting the chances of a fix by writing up a
patch myself.

Ticket: http://code.djangoproject.com/ticket/5416

I would like to know what experienced developers think of the patch.
Be kind, I am a newbie ;)

Thanks in advance.
--~--~-~--~~~---~--~~
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: USStateField (again)

[Russell Keith-Magee]

On Sat, Aug 22, 2009 at 7:49 PM, Tim
Chase wrote:
>
> James Bennett wrote:
>> The current proposal is for a "USPostalCodeField" which
>> corresponds to the US Postal Service's list of postal codes:
>>
>> http://www.usps.com/ncsc/lookups/abbr_state.txt
>>
>> [snip] Based on the various arguments up to this point, it
>> seems like no single field is going to make everybody happy,

Agreed that this particular argument is a recurring theme that we
should address.

> Internally, I've solved a similar "can't make everybody happy"
> problem with a class factory function that takes the desired set
> of defined data, depending on the project:

Given that the number of options is constrained, a fully-fledged
factory strikes me as overkill. Why not just booleans on the field
itself?

USStateField(lower_48=True, dc=True, non_contiguous=True,
protectorates=False, military_drops=True)

No need to deprecate anything - we can continue to ship USStateField
as is, just with some extra options that have default boolean values
set to reflect the currently enabled choices.

Given that US postal codes seems like a particularly common request,
there isn't much harm in including a a USPostalCodeField as a shortcut
- it's just a subclass with all the options set True.

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-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: USStateField (again)

[Tim Chase]

James Bennett wrote:
> The current proposal is for a "USPostalCodeField" which 
> corresponds to the US Postal Service's list of postal codes:
> 
> http://www.usps.com/ncsc/lookups/abbr_state.txt
> 
> [snip] Based on the various arguments up to this point, it
> seems like no single field is going to make everybody happy,

Internally, I've solved a similar "can't make everybody happy" 
problem with a class factory function that takes the desired set 
of defined data, depending on the project:

   LOWER_48 = [ ... ]
   US_STATES = sorted(# in shuffle AK/HI alphabetically
 LOWER_48 + [
 ('AK', 'Alaska'),
 ('HI', 'Hawaii')
 ],
 key=lambda s: s[1]
 )
   PROTECTORATES = [ ... ]
   MILITARY_DROPS = [ ... ]
   USPS_SERVICE = US_STATES + PROTECTORATES + MILITARY_DROPS

   class BaseStateField(Field):
 allowed_states = US_STATES
 # common logic/code here

   def make_state_field(desired_states=US_STATES):
 class MyStateField(BaseStateField):
   allowed_states = desired_states
 return MyStateField

which can then be used something like

   class MyModel(Model):
 just_48 = make_state_field()(help="Pick a lower48 state")
 all_us = make_state_field(US_STATES)(help="All the US")
 my_random_whims = make_state_field(
   US_STATES + PROTECTORATES)(help="Just what I wanted")

> First, deprecate USStateField immediately. It's not and never has been
> just a list of states, and the implication that the things it lists
> *are* US states seems to offend some people. So kill it, already.

With the above factory solution, one could just define it as

   USStateField = make_state_field(US_STATES + WHATEVER)

to prevent breaking existing code (though I agree the name is a 
bit misleading).  It also allows people to easily make a custom 
state-field with just the states they want:

   OUR_SALES_MARKET = [ ...subset of states here... ]
   SalesStates = make_state_field(OUR_SALES_MARKET)
   class MyModel(Model):
 sale_state = SalesStates(help="I sell stuff here...")

Just a possibility from the trenches here.

-tkc






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

USStateField (again)

[James Bennett]

So, the USStateField in contrib.localflavor got neutered a while back,
removing a number of items from its choices list which -- while not
actually US states -- are valid postal codes which the US Postal
Service recognizes and considers as "US" addresses. When this
happened, Django lost useful functionality: there's no longer any
field available that corresponds to what USPS will actually recognize.

And, predictably, now we've got ticket #9022 open, which started by
asking for support for US Armed Forces postal codes and has sort of
snowballed from there. The current proposal is for a
"USPostalCodeField" which corresponds to the US Postal Service's list
of postal codes:

http://www.usps.com/ncsc/lookups/abbr_state.txt

Since it's likely that any code change we end up making will be fairly
simple, I'd like to get the politics straightened out ASAP so that
Django 1.2 can have something that'll actually be useful. Based on the
various arguments up to this point, it seems like no single field is
going to make everybody happy, so here's what I'd suggest:

First, deprecate USStateField immediately. It's not and never has been
just a list of states, and the implication that the things it lists
*are* US states seems to offend some people. So kill it, already.

Then, add two new fields geared toward the actual real-world use cases:

1. A field for the 48 "contiguous" US states and the District of
Columbia. Lots of services restrict to this for shipping options.
2. A field which accepts anything the US Postal Service accepts. Call
it "USPostalCodeField" in line with the patch in #9022, or call it
"USPostalBikeshedField" for all I care. But get a field that equates
to what USPS allows.

If anybody can make a really good case for it, maybe we could do a
third field that's a restricted set of states and territories, but in
my experience places that'll ship to one overseas territory will
usually ship to them all, so I'd be inclined to leave that out.

If this sounds good, I can work up the patch and get it ready for
review Real Soon Now, and then hopefully we can put this to bed for
good.


-- 
"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: #10355 Add support for email backends

[Russell Keith-Magee]

On Sat, Aug 22, 2009 at 1:34 PM, Andi
Albrecht wrote:
>
> On Fri, Aug 21, 2009 at 1:45 PM, Russell
> Keith-Magee wrote:
>>
>> On Fri, Aug 21, 2009 at 5:53 PM, Zachary
>> Voase wrote:
>>>
>>> Hi Andi,
>>>
>>> On 21 Aug 2009, at 05:34, Andi Albrecht wrote:
>>>
 Hi,

 I'm interested in working on #10355 "Add support for email backends."

 IMHO it's an good idea to make the email backend configurable. There
 are at least two use cases I can think of. The first is to send email
 with other services than SMTP, like App Engine as noted in the
 ticket's description. The second is to deliver email asynchronously,
 like the django-mailer application does already.
>>>
>>> I wholeheartedly agree.
>>>
 The ticket currently needs a design decision, so my question is what
 the actual concerns to change this are.

 I would propose the following changes. It's a very simplistic approach
 that tries to keep the current API as much as possible:

 Add a new setting EMAIL_BACKEND. A string that can be resolved to a
 class. Default should be the current SMTP implementation.

 Provide a base class for mail backends. A mail backend must provide
 the method send_messages(email_messages) and must return the number of
 messages sent to provide backward compatibility. The constructor of a
 mail backend should take at least the keyword argument fail_silently
 (default: False). What I'm a bit unsure about are additional
 constructor arguments. Currently the SMTP backend allows in addition
 host, port, username, password and use_tls. Those are very
 SMTP-specific, but only username and password are used by the
 mail.send_mail* APIs. It would be an agreement to allow username and
 password in addition to fail_silently to not break the send_mail* API.
 The SMTP backend could accept host, port and use_tls as extra keywords
 again to provide backward compatibility for code that directly uses
 SMTPConnection (within Django SMTPConnection is not used outside
 django.core.mail). I would suggest to rename SMTPConnection to
 SMTPBackend, but only if this would break too much third-party code as
 SMTPConnection is mentioned in the docs.
>>>
>>> This I disagree with slightly. My main concern is the single-backend
>>> architecture; many websites will probably want to use more than one
>>> method for sending e-mail.
>>
>> I'm not sure I agree with your assertion of "many"."Some" might be
>> accurate. "Your" is probably more accurate :-)
>>
>> I've got many websites in the field, and not one of them has needed
>> anything more than trivial email handling. We've managed to get to
>> v1.1 and AppEngine support is the first time that pluggable email
>> backends have really been raised as an issue.
>>
>> This is hardly surprising. After all, email is email. You have an SMTP
>> server, you connect to it, you send your mail. AppEngine is a weird
>> case in that they provide an email-sending API rather than using SMTP,
>> but that's an artefact of the platform. Once you have one email
>> sending capability, I find it hard to believe that most people will
>> need a second.
>>
>> I don't doubt that there are applications that will require more than
>> one mail server, but I'm comfortable calling them edge cases. If you
>> have highly specialized mail requirements, then it makes sense that
>> you should have a highly specialized mail server handling.
>>
>> That said, there isn't really that much difference between the simple
>> and complex case - it's just a matter of defaults.
>>
>> Django needs to have a default Email backend, guaranteed available.
>>
>> EmailMessage.send() uses the 'default' backend - essentially just
>> calling backend.send_messages([msg])
>>
>> backend.send_messages() also exists as a direct call.
>> SMTPConnection().send_messages() is really just a shortcut for
>> instantiating and using an SMTP connection with the default settings.
>>
>> You're not compelled to use the default connection though. You could
>> instantiate multiple instances of different backends, and use them to
>> call other_backend.send_messages().
>>
>> I see this working almost exactly as the Cache backend works right
>> now. There is a base interface for caching. There are several cache
>> backends; dummy and locmem are handy for testing, but if you're
>> serious, the only one that gets used is memcached. There is a default
>> cache instantiated as a result of the CACHE_BACKEND setting. For most
>> people, this is all you will ever need. However, if you want to
>> instantiate (and use) multiple caches (e.g., if you want to get really
>> fancy about cache overflow and expiry policies), you can.
>>
>>> In addition, if mail backends only need to
>>> implement one method, why not just have EMAIL_BACKEND refer to a
>>> callable instead?
>>
>> Persistence