Re: [ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)

[Tom Evans]

On Mon, Dec 10, 2012 at 10:38 PM, James Bennett  wrote:
> Django 1.3.5, Django 1.4.3 and Django 1.5 beta 2 have just been issued
> in response to security issues.
>
> Details are available here:
>
> https://www.djangoproject.com/weblog/2012/dec/10/security/
>

Is the second part of the fix in any way optional? For instance, one
of my sites is a SAML/SSO identity provider - people log into it in
order to be granted access to other sites in the federation, and it is
routine for the "next" parameter during authentication to refer to any
site in the federation, not just the local domain.

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-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: [ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)

[Florian Apolloner]

Hi,

On Tuesday, December 11, 2012 11:31:17 AM UTC+1, Tom Evans wrote:
>
> Is the second part of the fix in any way optional?
>

Nope, there is no way to disable that behavior currently.

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/XczXwnTIYfMJ.
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.

Custom ordering using SQL backend

[Martin Winkler]

Hi all,

I recently solved a problem with a field that could not be ordered as I 
wanted. It was a CharField containing of exactly seven numbers like 
990, 010, 120 etc. The first two digits indicated a year (99 
being 1999 and 12 being 2012). The ordering should be different from usual, 
namely:
500, 501, ..., 000, 001, ... , 499. So I hacked around 
with a model manager, and a special QuerySet, and reached a state with 
which I was almost satisfied. See http://djangosnippets.org/snippets/2861/ 
for the whole stuff. 

There is even a special feature (totally optional) for databases which can 
do functional indexes to speed up the ordering. Sqlite would still work, 
although not quite as fast.

I can think of a  couple of other similar use cases e.g. a field containing 
strings like 'a1', 'a9', 'a10', 'a100' etc. where the usual alphanumeric 
sorting does not make sense.

If there is enough interest, I could dig into Django core to make this 
whole functionality more generic, so it could be merged into a development 
branch in Django.

I'd love to read some thoughts from you how / if I should continue from 
here.

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/-CV6h3o6z2YJ.
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.

Oracle backend bug makes testing on oracle slower?

[Shai Berger]

Hi all,

I've just been hit by a very simple and annoying bug on Oracle, on Django 
1.3.4. Without testing, it seems to no longer be as bad on master, but a shade 
of it still remains.

The bug is this: The DatabaseFeatures for the Oracle backend do not specify 
that it supports transactions. 

On 1.3.4, this means the value is only set if confirm() is called, and when it 
is, it only affects a single connection; it does not appear to be called 
whenever a connection is created -- while database test creation calls it, by 
the time the tests use it it is all forgotten and testing is relegated to the 
old behavior of flush for every test.

On master, where the generic supports_transactions is a cached property, this 
means that for every connection opened, 4 statements are being executed to 
check if the database (still) supports transactions.

1. Oracle supports transactions. is there a reason not to just add the line

supports_transactions = True

to its DatabaseFeatures class?

2. Database features, typically, do not change between opening of connections 
within a single server run. Shouldn't we consider saving these features -- 
even the dynamic ones -- on the DatabaseFeatures class, instead of its 
instances?

Thanks,
Shai.

-- 
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: Possible bug with GenericRelations and values_list

[Anssi Kääriäinen]

For what its worth this one should be fixed in the patch for ticket
#10790. After the patch the join condition will know the join field,
and the join field will be asked for extra join sql when generating
the join clause. This way it will be possible to append the content
type restriction into the JOIN clause instead of the WHERE clause.

 - Anssi

On 11 joulu, 06:45, Karen Tracey  wrote:
> On Mon, Dec 10, 2012 at 8:58 PM, Skylar Saveland
> wrote:
>
>
>
> > I posted this in the django-users group but I think it may merit posting
> > here, as well. I have a test case which I think should pass.
>
> >https://github.com/skyl/django/commit/556df1c46146c2fc9c4022d838fa23f...
>
> > Is this a bug? If so, is it a bug that is not in the tracker?
>
> I'd say it's a bug. I can't find an exact match in trac but I'd guess the
> root cause is similar to what's underlying:
>
> https://code.djangoproject.com/ticket/11387
>
> The SQL for the query in your test case that attempts to fetch the Animal
> object tags using values_list is:
>
> SELECT "generic_relations_taggeditem"."id" FROM "generic_relations_animal"
> LEFT OUTER JOIN "generic_relations_taggeditem" ON
> ("generic_relations_animal"."id" =
> "generic_relations_taggeditem"."object_id")
>
> This suffers from the same problem as the sql in #11387: it's not including
> any restriction on content type in the query, thus you can get tags that
> are pointing to non-Animals.
>
> 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-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.

UUID Field really wontfix?

[Thomas Guettler]

This ticket is closed since several years. Maybe it is time to think about it 
again.

Add UUID Field: https://code.djangoproject.com/ticket/4682


 Thomas Güttler


--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

--
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: Single table inheritance - working implementation

[Anssi Kääriäinen]

On 7 joulu, 16:18, Krzysztof Jurewicz 
wrote:
> On 29.10.2012 14:34, Krzysztof Jurewicz wrote:
>
> > In February, Craig de Stigter released django-typed-models
> > ,
> > a package implementing inheritance hierarchy for Proxy models with
> > automatic type recasting. I've written a fork of it with additional
> > possibility of adding fields to subclasses, therefore achieving a single
> > table inheritance implementation similar to Ruby on Rails' STI.
>
> Refreshing this thread because it looks like my fork stopped working
> properly with recent Django master. I suspect that commit c2e1e by Anssi
> K ri inen should be blamed for this, especially the line
>
> # Skip all proxy to the root proxied model
> opts = opts.concrete_model._meta
>
> in get_default_columns method. This causes it to generate potentially
> invalid set of columns for instantiated model because children typed
> models are implemented as proxy models and they have different set of
> fields than the root model, which stores all fields from its subclasses.
> In general having richer set of columns than required wouldn't be a
> problem, but those columns are used as positional arguments in model
> constructor and are therefore mapped incorrectly.
>
> I know that proxy models are intended to have the same set of fields as
> the root model and that I was relying on a completely internal
> implementation detail, so it has no chance of being treated as a bug,
> but that being said, I wonder if maybe Django could be changed to make
> such modifications easier. Currently I see the following solutions to
> the encountered problem:
>
> 1. Do not touch Django code directly and adjust django-typed-models to
> the changes made. This would probably require writing custom Manager
> class for TypedModel with custom QuerySet class which will use custom
> Query class with custom SQLCompiler class which will finally have
> get_default_columns method copy-paste-changed. Not an elegant solution.
>
> 2. Take a completely different approach to achieve single table
> inheritance ideas are welcome.
>
> 3. Modify Django code to be more friendly to django-typed-models.
> Current behavior of SQLCompiler looks a bit hackish to me, because in
> ideal world get_default_columns shouldn't care if a model is proxy or
> not this should be handled by model class internally. So perhaps
> another layer of abstraction could be added to Django ORM to allow
> internal handling of such special cases as proxy models. This would
> ideally allow to specify STI as a completely different model type than
> proxy model.
>
> 4. Add single table inheritance as a new inheritance type in Django.
>
> I'm not very familiar with Django ORM internals and additionally I don't
> know which of the above solutions have chances of getting approval by
> core devs, so feedback is welcome.

Would a model._meta.get_default_columns() work for you? While this
would still be internal API, it would be hopefully less likely to
change in ways that require extensive rewrites to 3rd party apps.

 - Anssi

-- 
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: UUID Field really wontfix?

[Jacob Kaplan-Moss]

If someone can come up with a good patch I'd be fine considering it for
core.

Jacob


On Tue, Dec 11, 2012 at 9:24 AM, Thomas Guettler  wrote:

> This ticket is closed since several years. Maybe it is time to think about
> it again.
>
> Add UUID Field: 
> https://code.djangoproject.**com/ticket/4682
>
>
>  Thomas Güttler
>
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> 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+unsubscribe@**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-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.

About GSoC 2013

[Mayur Patil]

Hi there,

   I want to ask is Django participating in the GSoC 2013??

  Waiting for your Reply.
-- 
*Cheers,*
*Mayur.*

-- 
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: About GSoC 2013

[Jacob Kaplan-Moss]

Hi Mayur --

You're a bit ahead of the curve here -- GSoC 2013 hasn't even been
announced yet. Once it is, we would have to apply and be accepted. All in
all, we won't know either way until around March.

Jacob


On Tue, Dec 11, 2012 at 10:31 AM, Mayur Patil wrote:

> Hi there,
>
>I want to ask is Django participating in the GSoC 2013??
>
>   Waiting for your Reply.
> --
> *Cheers,*
> *Mayur.*
>
> --
> 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.
>

-- 
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: Oracle backend bug makes testing on oracle slower?

[Ian Kelly]

On Tue, Dec 11, 2012 at 6:31 AM, Shai Berger  wrote:
> Hi all,
>
> I've just been hit by a very simple and annoying bug on Oracle, on Django
> 1.3.4. Without testing, it seems to no longer be as bad on master, but a shade
> of it still remains.
>
> The bug is this: The DatabaseFeatures for the Oracle backend do not specify
> that it supports transactions.
>
> On 1.3.4, this means the value is only set if confirm() is called, and when it
> is, it only affects a single connection; it does not appear to be called
> whenever a connection is created -- while database test creation calls it, by
> the time the tests use it it is all forgotten and testing is relegated to the
> old behavior of flush for every test.
>
> On master, where the generic supports_transactions is a cached property, this
> means that for every connection opened, 4 statements are being executed to
> check if the database (still) supports transactions.

While connections come and go, the DatabaseWrapper objects are stored
in the ConnectionHandler on a per-thread basis and should be reused
for subsequent connections.  So these tests *should* run only once per
configured connection per thread.  Can you demonstrate that they are
actually being run on every connection?

> 1. Oracle supports transactions. is there a reason not to just add the line
>
> supports_transactions = True
>
> to its DatabaseFeatures class?

I see no harm in it, although per the above I don't think it will help
as much as you hope.  Since the test involves a CREATE TABLE though,
and since DDL is slow in Oracle, and since there's really no guarantee
that the user even has the necessary permissions to create the table
in the first place, I think it's a good idea to add this in any case.

> 2. Database features, typically, do not change between opening of connections
> within a single server run. Shouldn't we consider saving these features --
> even the dynamic ones -- on the DatabaseFeatures class, instead of its
> instances?

This would lead to bugs in multi-DB setups where the user has
configured connections to multiple databases of the same type but
different versions (and different feature sets).  I don't know how
common that is, but it is better to be correct and slow than fast and
buggy.

-- 
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: Oracle backend bug makes testing on oracle slower?

[Shai Berger]

On Tuesday 11 December 2012, Ian Kelly wrote:
> On Tue, Dec 11, 2012 at 6:31 AM, Shai Berger  wrote:
> > Hi all,
> > 
> > I've just been hit by a very simple and annoying bug on Oracle, on Django
> > 1.3.4. Without testing, it seems to no longer be as bad on master, but a
> > shade of it still remains.
> > 
> > The bug is this: The DatabaseFeatures for the Oracle backend do not
> > specify that it supports transactions.
> > 
> > On 1.3.4, this means the value is only set if confirm() is called, and
> > when it is, it only affects a single connection; it does not appear to
> > be called whenever a connection is created -- while database test
> > creation calls it, by the time the tests use it it is all forgotten and
> > testing is relegated to the old behavior of flush for every test.
> > 
> > On master, where the generic supports_transactions is a cached property,
> > this means that for every connection opened, 4 statements are being
> > executed to check if the database (still) supports transactions.
> 
> While connections come and go, the DatabaseWrapper objects are stored
> in the ConnectionHandler on a per-thread basis and should be reused
> for subsequent connections.  So these tests *should* run only once per
> configured connection per thread.  Can you demonstrate that they are
> actually being run on every connection?
> 

As I noted above, I haven't actually tested on master, so I can't be sure; 
this was just my reading of the code. As far as I'm aware, though, the basic 
management of database wrappers and connections hasn't changed much since 1.3, 
and I can demonstrate that on 1.3.4, a new connection uses a new 
DatabaseFeatures object. I found this issue not by optimizing for speed, but 
by using a test-runner which installs some objects in the DB before running 
the test-suite; to my surprise, the objects weren't available, because the 
test framework, thinking the backend didn't support transactions, flushed the 
DB (as mentioned, on 1.3.4 the setting of supports_transactions takes a call 
to confirm(), but one is made, and running tests is single-threaded).

> > 1. Oracle supports transactions. is there a reason not to just add the
> > line
> > 
> > supports_transactions = True
> > 
> > to its DatabaseFeatures class?
> 
> I see no harm in it, although per the above I don't think it will help
> as much as you hope.  Since the test involves a CREATE TABLE though,
> and since DDL is slow in Oracle, and since there's really no guarantee
> that the user even has the necessary permissions to create the table
> in the first place, I think it's a good idea to add this in any case.
> 
Should I open a ticket for it? It is a one-line patch...

> > 2. Database features, typically, do not change between opening of
> > connections within a single server run. Shouldn't we consider saving
> > these features -- even the dynamic ones -- on the DatabaseFeatures
> > class, instead of its instances?
> 
> This would lead to bugs in multi-DB setups where the user has
> configured connections to multiple databases of the same type but
> different versions (and different feature sets).  I don't know how
> common that is, but it is better to be correct and slow than fast and
> buggy.

While I doubt that such setups are common enough to justify a price paid by 
the whole community, I can accept this answer as "we considered it and decided 
against". But then, I would ask for backends to rely as little as possible on 
dynamic features. A user can easily monkey-patch sense into the backend 
DatabaseFeatures, but that's no replacement for sensible defaults.

Thanks,
Shai.

-- 
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: Oracle backend bug makes testing on oracle slower?

[Florian Apolloner]

On Tuesday, December 11, 2012 8:53:55 PM UTC+1, Shai Berger wrote:
>
> Should I open a ticket for it? It is a one-line patch... 
>

Please try to test this on master first, we most likely won't patch 1.3.

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/DS4ghzP6SNcJ.
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: Oracle backend bug makes testing on oracle slower?

[Shai Berger]

On Tuesday 11 December 2012, Florian Apolloner wrote:
> On Tuesday, December 11, 2012 8:53:55 PM UTC+1, Shai Berger wrote:
> > Should I open a ticket for it? It is a one-line patch...
> 
> Please try to test this on master first, we most likely won't patch 1.3.
> 
This was referring only to the setting of supports_transactions on Oracle, 
which Ian appeared to support. I had no illusions that it would be ported to 
1.3 or even 1.4 (and I have an easy workaround for these versions anyway).

Thanks,
Shai.

-- 
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: [ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)

[Yo-Yo Ma]

Tom,

Create a view that accepts a "uri" argument and returns a 302 to the provided 
URI. Then, update your redirect_to callable to urlencode the URI and send them 
to /your/redirect/view/?uri=[encoded URI] and problem solved. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rVxzz8Z5ubsJ.
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.