Re: Possible bug in messages framework?

2010-01-22 Thread Luke Plant
On Saturday 23 January 2010 02:44:39 Luke Plant wrote:

>  BTW, further research shows that we are not really RFC 2109
>  compliant at all, but then again no-one is.  It seems virtually
>  everyone (server side and client side) is using 'Netscape style'
>  cookies with some things adopted from RFC 2109 and RFC 2965,
>  including 'max-age' and the use of quoted-string, but not the all
>  important "Version" attribute which turns on RFC 2109 cookies. 
>  Hardly anyone is using Set-Cookie2 from RFC 2965.  So specs of any
>  kind are fairly meaningless here, it's a matter of what everyone
>  does.

Actually, to add a bit more:

http://www.ietf.org/mail-archive/web/http-state/current/msg00078.html
http://codereview.chromium.org/17045

It's all pretty horrific, it pushes me back towards adding a layer of 
quoting to our cookie handling just to try to avoid it all - but a 
robust encoding which definitely avoids all problems.  We should note 
that the presence of semi-colons is more likely to cause problems than 
commas - Internet Explorer splits on semi-colons, irrespective of 
quotation marks.

Luke

-- 
Sometimes I wonder if men and women really suit each other. Perhaps 
they should live next door and just visit now and then. (Katherine 
Hepburn)

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: Possible bug in messages framework?

2010-01-22 Thread Luke Plant
On Saturday 23 January 2010 01:20:55 Sean Brant wrote:

> Whats the downside of fixing this at the core cookie handling
>  level? I agree with Luke and only ran across this bug when the new
>  messaging framework dropped. However if we are going to fix the
>  problem, and I do think it's a problem even if its a browser bug,
>  should we just fix it at the core level and handle all cookies
>  down the road? Would previously stored cookies that are not url
>  quoted even fail when trying to unquote? Maybe I'm wrong but this
>  seems pretty backwards compatible.

It's true that the vast majority of existing cookie values will be 
interpreted the same whether you URL-unquote or not. i.e.

 unquote_cookie(value) == value

in many cases so this isn't a big deal.  But it's not *always* true, 
otherwise there is no need for unquote_cookie.  And every time it's 
not true is a potential bug with previously stored cookies.  The most 
likely scenario I can think of is if a cookie is being used to store 
some query string or previous URL (like a saved search), which might 
then be used literally in some way (e.g. as the parameter to 
HttpResponseRedirect).  By URL unquoting, when we didn't before, we 
would introduce a bug.

e.g. 
 HttpResponseRedirect("http://foo.com/?q=fr%C3%A8re;)

is not the same as

 HttpResponseRedirect("http://foo.com/?q=fr\xc3\xa8re;)

(the latter throws an exception in this case).

BTW, Turbogears' solution is actually buggy for some input:

>>> assert unquote_cookie(quote_cookie("%25")) == "%25"
Traceback (most recent call last):
  File "", line 1, in 
AssertionError

Coming up with your own encoding is sometimes tricker than it looks.

I don't think this is a big deal because, either way, I don't think 
many people are going to be affected.

BTW, further research shows that we are not really RFC 2109 compliant 
at all, but then again no-one is.  It seems virtually everyone (server 
side and client side) is using 'Netscape style' cookies with some 
things adopted from RFC 2109 and RFC 2965, including 'max-age' and the 
use of quoted-string, but not the all important "Version" attribute 
which turns on RFC 2109 cookies.  Hardly anyone is using Set-Cookie2 
from RFC 2965.  So specs of any kind are fairly meaningless here, it's 
a matter of what everyone does.


Luke

-- 
Sometimes I wonder if men and women really suit each other. Perhaps 
they should live next door and just visit now and then. (Katherine 
Hepburn)

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: Possible bug in messages framework?

2010-01-22 Thread Sean Brant

On Jan 22, 2010, at 7:04 PM, Luke Plant wrote:

> Well, it depends on what you call the 'spec'.  What spec says that 
> commas in values is invalid?
> 
> The 'spec' linked to on that WebKit bug is a preliminary Netscape 
> document, which, as far as I can tell, eventually turned into RFC 
> 2109, which surely has got to be regarded as more authoritative.  RFC 
> 2965 (which proposes Set-Cookie2) supposedly obsoletes RFC 2109, but I 
> don't know think it is really used much. [1]
> 
> As I noted on the bug [2], RFC 2109 allows values to be quoted, in 
> which case Django is behaving correctly, and it is some browsers that 
> are not.
> 
> Our implementation of this is in fact done entirely by Python's 
> standard library Cookie module [3]. It handles everything I can throw 
> at it (newlines, UTF8, throws exceptions with illegal cookie names 
> etc.).  It's kind of unlikely that we've found a bug in it.
> 
> Of course, it doesn't mean we shouldn't fix things to avoid this bug.  
> But to do so would require some kind of encoding, which is almost 
> certainly going to cause breakage of some kind with existing cookies.  
> Turbogears' solution would be backwards compatible in most cases, but 
> not all.
> 
> (BTW, if we implemented this change, the nicer way to do is to 
> subclass Cookie and override Cookie.value_encode() and value_decode(), 
> rather than the way that Turbogears does it)
> 
> Personally, I favour fixing our messages implementation so that it 
> isn't an issue (which is easy, it seems, see details on #12470), and 
> possibly just putting a note into our cookie documentation that some 
> old WebKit based browsers have a bug that means they do not correctly 
> handle a cookie value containing a comma followed by a space.
> 
> An argument in favour of this lazy approach is that this issue, for 
> both ourselves and Turbogears, has only ever come up in the context of 
> using cookies for messages.  Presumably that means that developers are 
> rarely storing extended human readable text strings in cookies outside 
> of this kind of usage, so outside of the messages app it is probably 
> not something we need to worry about.
> 
> Luke


Whats the downside of fixing this at the core cookie handling level? I agree 
with Luke and only ran across this bug when the new messaging framework 
dropped. However if we are going to fix the problem, and I do think it's a 
problem even if its a browser bug, should we just fix it at the core level and 
handle all cookies down the road? Would previously stored cookies that are not 
url quoted even fail when trying to unquote? Maybe I'm wrong but this seems 
pretty backwards compatible.

Sean

-- 
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: Possible bug in messages framework?

2010-01-22 Thread Luke Plant
On Friday 22 January 2010 19:20:20 Vinay Sajip wrote:
> On Jan 22, 1:53 pm, SmileyChris  wrote:
> > If we're to accept that turbogears example, it sounds like we're
> > not properly encoding the cookie in core, rather than patching
> > messages.
> 
> Yes, it appears to be a matter of luck that other browsers accept
> cookie values which are invalid according to the cookie spec. This
> comment on a Webkit bug has  useful information:
> 
> https://bugs.webkit.org/show_bug.cgi?id=6063#c7

Well, it depends on what you call the 'spec'.  What spec says that 
commas in values is invalid?

The 'spec' linked to on that WebKit bug is a preliminary Netscape 
document, which, as far as I can tell, eventually turned into RFC 
2109, which surely has got to be regarded as more authoritative.  RFC 
2965 (which proposes Set-Cookie2) supposedly obsoletes RFC 2109, but I 
don't know think it is really used much. [1]

As I noted on the bug [2], RFC 2109 allows values to be quoted, in 
which case Django is behaving correctly, and it is some browsers that 
are not.

Our implementation of this is in fact done entirely by Python's 
standard library Cookie module [3]. It handles everything I can throw 
at it (newlines, UTF8, throws exceptions with illegal cookie names 
etc.).  It's kind of unlikely that we've found a bug in it.

Of course, it doesn't mean we shouldn't fix things to avoid this bug.  
But to do so would require some kind of encoding, which is almost 
certainly going to cause breakage of some kind with existing cookies.  
Turbogears' solution would be backwards compatible in most cases, but 
not all.

(BTW, if we implemented this change, the nicer way to do is to 
subclass Cookie and override Cookie.value_encode() and value_decode(), 
rather than the way that Turbogears does it)

Personally, I favour fixing our messages implementation so that it 
isn't an issue (which is easy, it seems, see details on #12470), and 
possibly just putting a note into our cookie documentation that some 
old WebKit based browsers have a bug that means they do not correctly 
handle a cookie value containing a comma followed by a space.

An argument in favour of this lazy approach is that this issue, for 
both ourselves and Turbogears, has only ever come up in the context of 
using cookies for messages.  Presumably that means that developers are 
rarely storing extended human readable text strings in cookies outside 
of this kind of usage, so outside of the messages app it is probably 
not something we need to worry about.

Luke

[1] http://code.google.com/webstats/2005-12/httpheaders.html
[2] http://code.djangoproject.com/ticket/12470#comment:4
[3] http://docs.python.org/library/cookie.html

-- 
Sometimes I wonder if men and women really suit each other. Perhaps 
they should live next door and just visit now and then. (Katherine 
Hepburn)

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: Possible bug in messages framework?

2010-01-22 Thread Vinay Sajip
On Jan 22, 1:53 pm, SmileyChris  wrote:
> If we're to accept that turbogears example, it sounds like we're not
> properly encoding the cookie in core, rather than patching messages.

Yes, it appears to be a matter of luck that other browsers accept
cookie values which are invalid according to the cookie spec. This
comment on a Webkit bug has  useful information:

https://bugs.webkit.org/show_bug.cgi?id=6063#c7

Regards,

Vinay Sajip

-- 
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: Possible bug in messages framework?

2010-01-22 Thread SmileyChris
Looking around, this looks like a problem for other frameworks too
(see http://trac.turbogears.org/ticket/1164)
If we're to accept that turbogears example, it sounds like we're not
properly encoding the cookie in core, rather than patching messages.

On Jan 23, 2:23 am, Tobias McNulty  wrote:
> Hi Jeff,
>
> Could you try again without a comma in the message and see if the
> CookieStorage starts working again?  Either way, that definitely sounds like
> a bug to me.
>
> Thanks,
> Tobias
>
> On Fri, Jan 22, 2010 at 12:13 AM, j...@jeffcroft.com 
> wrote:
>
>
>
>
>
> > Sean-
>
> > Can't say for sure it's related, but I can verify that I was using
> > Safari (Mobile) and that my message had commas in them...so it
> > definitely could be.
>
> > Switching to session storage solved the problem for me, and that
> > backend works fine for my needs. So, it's no longer  pressing issue
> > for me, but there definitely seems to be something wrong in the cookie
> > storage backend.
>
> > Jeff
>
> > On Jan 21, 9:07 pm, Sean Brant  wrote:
> > > I wonder if this is related?
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > > On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:
>
> > > > After a little more playing around, I've discovered that this is not
> > > > an issue if I use the session storage -- so it seems to be related to
> > > > cookie storage.
>
> > > > --
> > > > 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 athttp://
> > 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 > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-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: Crash/BUG: Models.annotate(...).exclude(...) gives AttributeError

2010-01-22 Thread Yuri Baburov
Hi Asgeir,

Cool, thanks.

According to http://docs.djangoproject.com/en/dev/internals/contributing/ ,
before someone will look closer at the problem,
could you please create a) a ticket describing this problem, and b)
create a test case demonstrating the problem?

On Fri, Jan 22, 2010 at 7:04 PM, AsgeirM  wrote:
> The problem:
>
> When using annotate on a queryset from objects.all() and then using an
> exclude via a related table, accessing the queryset causes an
> AttributeError.
>
> Please note that excluding first, and then calling annotate works.
> This is however not possible in my case, because I want the annotate
> field to be included in the queryset that the objects manager returns.
>
> I've attached code from a shell to illustrate the problem:
>
> Python 2.4.3 (#1, Sep  3 2009, 15:37:12)
> IPython 0.8.4 -- An enhanced Interactive Python.
> django (1, 1, 0, 'final', 0)
>
> In [1]: from core.models import *
> In [2]: from django.db.models import get_model, Q, Count, Sum, Min
>
> In [3]: print InvoiceLine.objects.all().exclude(invoice__flag__in=
> ('f')).annotate(test=Sum('invoice__id')).query
> < Works >
>
> In [4]: print InvoiceLine.objects.all().annotate(test=Sum
> ('invoice__id')).exclude(invoice__flag__in=('f')).query
> ---
> AttributeError                            Traceback (most recent call
> last)
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
> __str__(self)
>    111         done by the database interface at execution time.
>    112         """
> --> 113         sql, params = self.as_sql()
>    114         return sql % params
>    115
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
> as_sql(self, with_limits, with_col_aliases)
>    402
>    403         qn = self.quote_name_unless_alias
> --> 404         where, w_params = self.where.as_sql(qn=qn)
>    405         having, h_params = self.having.as_sql(qn=qn)
>    406         params = []
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> as_sql(self, qn)
>     98             try:
>     99                 if hasattr(child, 'as_sql'):
> --> 100                     sql, params = child.as_sql(qn=qn)
>    101                 else:
>    102                     # A leaf node in the tree.
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> as_sql(self, qn)
>     98             try:
>     99                 if hasattr(child, 'as_sql'):
> --> 100                     sql, params = child.as_sql(qn=qn)
>    101                 else:
>    102                     # A leaf node in the tree.
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> as_sql(self, qn)
>     98             try:
>     99                 if hasattr(child, 'as_sql'):
> --> 100                     sql, params = child.as_sql(qn=qn)
>    101                 else:
>    102                     # A leaf node in the tree.
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> as_sql(self, qn)
>    101                 else:
>    102                     # A leaf node in the tree.
> --> 103                     sql, params = self.make_atom(child, qn)
>    104
>    105             except EmptyResultSet:
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> make_atom(self, child, qn)
>    148         if isinstance(lvalue, tuple):
>    149             # A direct database column lookup.
> --> 150             field_sql = self.sql_for_columns(lvalue, qn)
>    151         else:
>    152             # A smart object with an as_sql() method.
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
> sql_for_columns(self, data, qn)
>    200         table_alias, name, db_type = data
>    201         if table_alias:
> --> 202             lhs = '%s.%s' % (qn(table_alias), qn(name))
>    203         else:
>    204             lhs = qn(name)
>
> /usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
> quote_name_unless_alias(self, name)
>    173             self.quote_cache[name] = name
>    174             return name
> --> 175         r = self.connection.ops.quote_name(name)
>    176         self.quote_cache[name] = r
>    177         return r
>
> /usr/lib/python2.4/site-packages/django/db/backends/postgresql/
> operations.pyc in quote_name(self, name)
>     61
>     62     def quote_name(self, name):
> ---> 63         if name.startswith('"') and name.endswith('"'):
>     64             return name # Quoting once is enough.
>     65         return '"%s"' % name
>
> AttributeError: 'NoneType' object has no attribute 'startswith'

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 

Re: What The Enterprise wants from Django

2010-01-22 Thread PauloS
On Jan 20, 3:15 pm, sago  wrote:
> I've had one very long and complex issue with a major client over
> legacy databases with Composite Primary Keys (and other composite keys
> more generally), an issue which has also come up in other contexts.
> One of my smaller clients switched to a strange bastardization of
> Django and SQLAlchemy because this was an issue. I understand the
> history of #373 and why it is hard - just for disclosure.

Composite primary keys is a major issue over here and we also ended up
with a bastard of SQLAlchemy and Django.

--
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: Fully Polymorphic Django Models: a simple implementation

2010-01-22 Thread hejsan
This is the best news I've heard for a long time!

This was also my biggest disappointment with Django. This bit me in my
first django project, which incidentally was also my first experience
with ORM.

Basically I had the following class structure:

Project
 Art Project
 Research Project
 Lecture
...
And I wanted to allow the projects to link each other for a "Related
projects" feature... i figured it would be easy, just:
Project.objects.all()...but no, impossible.
Then I figured out that ORM != OO

This elementary feature should be merged into the basic django Model
class IMO.

On Jan 22, 1:00 pm, rvdrijst  wrote:
> Wow, amazing job!
>
> This addresses the big disappointment I felt when I found out django
> Model Inheritance didn't do this by default. I used some ugly
> workarounds to make it happen and this seems like the perfect
> solution. Main problem is that it requires django 1.1, I'm working
> with trunk/1.2, but I'm going to give it a try anyway.
>
> I'll keep tracking the developments on github, keep up the good work!
>
> - Robin
>
> On Jan 15, 8:55 pm, Bert Constantin  wrote:
>
> > Hello everyone!
>
> > I just uploaded a simple but mostly complete implementation of model
> > and queryset polymorphism onto github and bitbucket.
>
> > For enabled models, this implementation simply makes all references
> > to the model's objects polymorphic (be it managers/querysets or
> > relationship fields).
>
> > The prototype might be useful as a tool for concretely exploring the
> > concept of polymorphic models within the Django framework (and
> > perhaps might find use in real projects as well).
>
> > My impression is that fully polymorphic models and querysets
> > integrate very well into the Django ORM and database API. Also, with
> > Django's ORM and model inheritance system, all the heavy lifting
> > has already been done; only a rather thin layer above seems
> > to be required to get to a complete implementation of polymorphic
> > inheritance.
>
> > Below I copied the docstring of the module.
> > Near the top are a number of short examples that are good as a quick
> > overview.
>
> > The docstring can be read in a much better format 
> > here:http://bserve.webhop.org/wiki/django_polymorphic
>
> > Suggestions and criticism are very welcome.
>
> > Kind Regards,
> > Bert Constantin
>
> > GitHub:http://github.com/bconstantin/django_polymorphic
> > Bitbucket:http://bitbucket.org/bconstantin/django_polymorphic
> > Tar:http://github.com/bconstantin/django_polymorphic/tarball/master
>
> > +++
>
> > Defining Polymorphic Models
> > ===
>
> > To make models polymorphic, use PolymorphicModel instead of Django's
> > models.Model as the superclass of your base model. All models
> > inheriting from your base class will be polymorphic as well::
>
> >     from polymorphic import PolymorphicModel
>
> >     class ModelA(PolymorphicModel):
> >         field1 = models.CharField(max_length=10)
>
> >     class ModelB(ModelA):
> >         field2 = models.CharField(max_length=10)
>
> >     class ModelC(ModelB):
> >         field3 = models.CharField(max_length=10)
>
> > Using Polymorphic Models
> > 
>
> > Most of Django's standard ORM functionality is available
> > and works as expected:
>
> > Create some objects
> > ---
>
> >     >>> ModelA.objects.create(field1='A1')
> >     >>> ModelB.objects.create(field1='B1', field2='B2')
> >     >>> ModelC.objects.create(field1='C1', field2='C2', field3='C3')
>
> > Query results are polymorphic
> > -
>
> >     >>> ModelA.objects.all()
> >     .
> >     [ ,
> >       ,
> >        > (CharField)> ]
>
> > Filtering for classes (equivalent to python's isinstance() ):
> > -
>
> >     >>> ModelA.objects.instance_of(ModelB)
> >     .
> >     [ ,
> >        > (CharField)> ]
>
> >     In general, including or excluding parts of the inheritance tree::
>
> >         ModelA.objects.instance_of(ModelB [, ModelC ...])
> >         ModelA.objects.not_instance_of(ModelB [, ModelC ...])
>
> > Polymorphic filtering (for fields in derived classes)
> > -
>
> >     For example, cherrypicking objects from multiple derived classes
> >     anywhere in the inheritance tree, using Q objects (with the
> >     slightly enhanced syntax: exact model name + three _ + field
> > name):
>
> >     >>> ModelA.objects.filter(  Q( ModelB___field2 = 'B2' )  |  Q
> > ( ModelC___field3 = 'C3' )  )
> >     .
> >     [ ,
> >        > (CharField)> ]
>
> > Combining Querysets of different types/models
> > -
>
> >     Querysets may now be regarded as object containers that allow the
> >     aggregation of  different object types - very similar to python
> >     lists (as long as the objects are accessed through the manager of
> >  

Crash/BUG: Models.annotate(...).exclude(...) gives AttributeError

2010-01-22 Thread AsgeirM
The problem:

When using annotate on a queryset from objects.all() and then using an
exclude via a related table, accessing the queryset causes an
AttributeError.

Please note that excluding first, and then calling annotate works.
This is however not possible in my case, because I want the annotate
field to be included in the queryset that the objects manager returns.

I've attached code from a shell to illustrate the problem:

Python 2.4.3 (#1, Sep  3 2009, 15:37:12)
IPython 0.8.4 -- An enhanced Interactive Python.
django (1, 1, 0, 'final', 0)

In [1]: from core.models import *
In [2]: from django.db.models import get_model, Q, Count, Sum, Min

In [3]: print InvoiceLine.objects.all().exclude(invoice__flag__in=
('f')).annotate(test=Sum('invoice__id')).query
< Works >

In [4]: print InvoiceLine.objects.all().annotate(test=Sum
('invoice__id')).exclude(invoice__flag__in=('f')).query
---
AttributeErrorTraceback (most recent call
last)

/usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
__str__(self)
111 done by the database interface at execution time.
112 """
--> 113 sql, params = self.as_sql()
114 return sql % params
115

/usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
as_sql(self, with_limits, with_col_aliases)
402
403 qn = self.quote_name_unless_alias
--> 404 where, w_params = self.where.as_sql(qn=qn)
405 having, h_params = self.having.as_sql(qn=qn)
406 params = []

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
as_sql(self, qn)
 98 try:
 99 if hasattr(child, 'as_sql'):
--> 100 sql, params = child.as_sql(qn=qn)
101 else:
102 # A leaf node in the tree.

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
as_sql(self, qn)
 98 try:
 99 if hasattr(child, 'as_sql'):
--> 100 sql, params = child.as_sql(qn=qn)
101 else:
102 # A leaf node in the tree.

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
as_sql(self, qn)
 98 try:
 99 if hasattr(child, 'as_sql'):
--> 100 sql, params = child.as_sql(qn=qn)
101 else:
102 # A leaf node in the tree.

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
as_sql(self, qn)
101 else:
102 # A leaf node in the tree.
--> 103 sql, params = self.make_atom(child, qn)
104
105 except EmptyResultSet:

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
make_atom(self, child, qn)
148 if isinstance(lvalue, tuple):
149 # A direct database column lookup.
--> 150 field_sql = self.sql_for_columns(lvalue, qn)
151 else:
152 # A smart object with an as_sql() method.

/usr/lib/python2.4/site-packages/django/db/models/sql/where.pyc in
sql_for_columns(self, data, qn)
200 table_alias, name, db_type = data
201 if table_alias:
--> 202 lhs = '%s.%s' % (qn(table_alias), qn(name))
203 else:
204 lhs = qn(name)

/usr/lib/python2.4/site-packages/django/db/models/sql/query.pyc in
quote_name_unless_alias(self, name)
173 self.quote_cache[name] = name
174 return name
--> 175 r = self.connection.ops.quote_name(name)
176 self.quote_cache[name] = r
177 return r

/usr/lib/python2.4/site-packages/django/db/backends/postgresql/
operations.pyc in quote_name(self, name)
 61
 62 def quote_name(self, name):
---> 63 if name.startswith('"') and name.endswith('"'):
 64 return name # Quoting once is enough.
 65 return '"%s"' % name

AttributeError: 'NoneType' object has no attribute 'startswith'

-- 
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: Possible bug in messages framework?

2010-01-22 Thread Tobias McNulty
Hi Jeff,

Could you try again without a comma in the message and see if the
CookieStorage starts working again?  Either way, that definitely sounds like
a bug to me.

Thanks,
Tobias

On Fri, Jan 22, 2010 at 12:13 AM, j...@jeffcroft.com wrote:

> Sean-
>
> Can't say for sure it's related, but I can verify that I was using
> Safari (Mobile) and that my message had commas in them...so it
> definitely could be.
>
> Switching to session storage solved the problem for me, and that
> backend works fine for my needs. So, it's no longer  pressing issue
> for me, but there definitely seems to be something wrong in the cookie
> storage backend.
>
> Jeff
>
> On Jan 21, 9:07 pm, Sean Brant  wrote:
> > I wonder if this is related?
> http://groups.google.com/group/django-developers/browse_thread/thread...
> >
> > On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:
> >
> >
> >
> > > After a little more playing around, I've discovered that this is not
> > > an issue if I use the session storage -- so it seems to be related to
> > > cookie storage.
> >
> > > --
> > > 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 athttp://
> 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.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-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: Fully Polymorphic Django Models: a simple implementation

2010-01-22 Thread rvdrijst
Wow, amazing job!

This addresses the big disappointment I felt when I found out django
Model Inheritance didn't do this by default. I used some ugly
workarounds to make it happen and this seems like the perfect
solution. Main problem is that it requires django 1.1, I'm working
with trunk/1.2, but I'm going to give it a try anyway.

I'll keep tracking the developments on github, keep up the good work!

- Robin

On Jan 15, 8:55 pm, Bert Constantin  wrote:
> Hello everyone!
>
> I just uploaded a simple but mostly complete implementation of model
> and queryset polymorphism onto github and bitbucket.
>
> For enabled models, this implementation simply makes all references
> to the model's objects polymorphic (be it managers/querysets or
> relationship fields).
>
> The prototype might be useful as a tool for concretely exploring the
> concept of polymorphic models within the Django framework (and
> perhaps might find use in real projects as well).
>
> My impression is that fully polymorphic models and querysets
> integrate very well into the Django ORM and database API. Also, with
> Django's ORM and model inheritance system, all the heavy lifting
> has already been done; only a rather thin layer above seems
> to be required to get to a complete implementation of polymorphic
> inheritance.
>
> Below I copied the docstring of the module.
> Near the top are a number of short examples that are good as a quick
> overview.
>
> The docstring can be read in a much better format 
> here:http://bserve.webhop.org/wiki/django_polymorphic
>
> Suggestions and criticism are very welcome.
>
> Kind Regards,
> Bert Constantin
>
> GitHub:http://github.com/bconstantin/django_polymorphic
> Bitbucket:http://bitbucket.org/bconstantin/django_polymorphic
> Tar:http://github.com/bconstantin/django_polymorphic/tarball/master
>
> +++
>
> Defining Polymorphic Models
> ===
>
> To make models polymorphic, use PolymorphicModel instead of Django's
> models.Model as the superclass of your base model. All models
> inheriting from your base class will be polymorphic as well::
>
>     from polymorphic import PolymorphicModel
>
>     class ModelA(PolymorphicModel):
>         field1 = models.CharField(max_length=10)
>
>     class ModelB(ModelA):
>         field2 = models.CharField(max_length=10)
>
>     class ModelC(ModelB):
>         field3 = models.CharField(max_length=10)
>
> Using Polymorphic Models
> 
>
> Most of Django's standard ORM functionality is available
> and works as expected:
>
> Create some objects
> ---
>
>     >>> ModelA.objects.create(field1='A1')
>     >>> ModelB.objects.create(field1='B1', field2='B2')
>     >>> ModelC.objects.create(field1='C1', field2='C2', field3='C3')
>
> Query results are polymorphic
> -
>
>     >>> ModelA.objects.all()
>     .
>     [ ,
>       ,
>        (CharField)> ]
>
> Filtering for classes (equivalent to python's isinstance() ):
> -
>
>     >>> ModelA.objects.instance_of(ModelB)
>     .
>     [ ,
>        (CharField)> ]
>
>     In general, including or excluding parts of the inheritance tree::
>
>         ModelA.objects.instance_of(ModelB [, ModelC ...])
>         ModelA.objects.not_instance_of(ModelB [, ModelC ...])
>
> Polymorphic filtering (for fields in derived classes)
> -
>
>     For example, cherrypicking objects from multiple derived classes
>     anywhere in the inheritance tree, using Q objects (with the
>     slightly enhanced syntax: exact model name + three _ + field
> name):
>
>     >>> ModelA.objects.filter(  Q( ModelB___field2 = 'B2' )  |  Q
> ( ModelC___field3 = 'C3' )  )
>     .
>     [ ,
>        (CharField)> ]
>
> Combining Querysets of different types/models
> -
>
>     Querysets may now be regarded as object containers that allow the
>     aggregation of  different object types - very similar to python
>     lists (as long as the objects are accessed through the manager of
>     a common base class):
>
>     >>> Base.objects.instance_of(ModelX) | Base.objects.instance_of
> (ModelY)
>     .
>     [ ,
>        ]
>
> Using Third Party Models (without modifying them)
> -
>
>     Third party models can be used as polymorphic models without any
>     restrictions by simply subclassing them. E.g. using a third party
>     model as the root of a polymorphic inheritance tree::
>
>         from thirdparty import ThirdPartyModel
>
>         class MyThirdPartyModel(PolymorhpicModel, ThirdPartyModel):
>             pass    # or add fields
>
>     Or instead integrating the third party model anywhere into an
>     existing polymorphic inheritance tree::
>
>         class MyModel(SomePolymorphicModel):
>             my_field = models.CharField(max_length=10)
>
>         

Re: Suggestion: DictionaryField

2010-01-22 Thread veena
Hi,
I must correct my post. When I used "default" option I mean "choices"
option.

On 18 led, 22:23, Михаил Лукин  wrote:
> There is no need in ENUM functionality since 'choices=' option exists.

I must disagree with you. It looks like choices emulate ENUM but it's
not true.
What's not supported:
- model validating: no other values except that in choices are valid
- support for binary representation of values and binary matching in
ORM queries

For SETs there's another condition:
- unique values in SETs


Vaclav



> Representing ENUM and SET as input fields even with autocompletion may be
> confusing in multi-language applications.

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



Looking for Django / Python Developers in Edinburgh

2010-01-22 Thread mercurytide
Established in 2001, Mercurytide is an industry expert in web
development, with offices in both Edinburgh and Glasgow.  We only
employ individuals of an expectantly high standard and use Django as
our main platform.

We are looking to recruit for the following positions for our
Edinburgh office:

Django / Python Developers
The role will involve both implementing a site design in XHTML, CSS
and JavaScript, and the corresponding back end development to produce
advanced, database-driven dynamic sites. We have multiple roles to
fill and are looking for good developers at all levels of experience.
If you only know PHP and are eager to convert to Django then we may
still be interested.  The role will involve designing the architecture
of solutions as well as developing well crafted, readable and
maintainable code.  Knowledge of related technologies including SQL
and XML would also be advantageous.

iPhone App Developer
The role will involve developing new iPhone applications from scratch
for new and existing clients so experience of developing commercial
applications is essential.
You should have experience in Objective-C and a knowledge of
interfacing mobile applications to third party systems.  The role will
involve designing the architecture of solutions as well as developing
well crafted, readable and maintainable code.

Web Developer
The role will involve both implementing a site design in XHTML, CSS
and JavaScript, and the corresponding back end development to produce
advanced, database-driven dynamic sites. As our main platform is
Django, experience of object orientated languages is essential. PHP
experience will be considered as a transferable skill, although the
company does not use this technology.  Understanding of standards-
based Web development and producing accessible sites is a key
requirement. The successful candidate will need to become self
sufficient in Python and related technologies including SQL and XML.
The position will involve designing the architecture of solutions as
well as developing well crafted, readable and maintainable code.

This is an outstanding opportunity to join an established but growing
team of web developers working with cutting edge technologies.

To apply for any of these positions please email your CV to
j...@mercurytide.co.uk or give us a call on 0845 652 6506.
www.mercurytide.co.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.