date:20110802

Re: [Django] #16559: Switch to entity-manager type system.

2011-08-02 Thread Django

#16559: Switch to entity-manager type system.
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone:  2.0|  Component:  Uncategorized
Version:  1.3-rc1|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by russellm):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 I'm closing this ticket for a number of reasons.

 Firstly, Trac is completely the wrong forum in which to have this
 discussion. You're proposing a *major* change to Django's ORM. Even if we
 accept as given the proposition that this is a great idea, it's something
 that would need to be discussed extensively in the Django community before
 we decided to go forward. As is documented in our
 [https://docs.djangoproject.com/en/1.3/internals/contributing/
 contributing guide], Trac isn't the place to have that discussion.

 Secondly, I'm particularly wary of any suggestion that takes the form of
 "Django would be awesome if only it were completely different",
 *especially* when it comes from an anonymous contributor. If you take off
 your mask and reveal yourself to be someone with great experience in the
 Django community or in ORM circles, then your claims would carry a bit
 more weight.

 Thirdly,  I don't accept your proposition that this would be an
 improvement. From the link you provided, it isn't clear to me why the
 abstraction would be a clear and obvious improvement to the ORM model. At
 best, it looks like it might be a way to implement #4102 -- and we can do
 that without making a massive change to the ORM.

 Fourth, if Django were to make a massive ORM change, I'd lay money that
 the most likely proposition to be accepted would be "make Django's ORM a
 wrapper around SQLAlchemy", or something of that ilk.

 Lastly, blue sky propositions like this don't go anywhere unless there is
 someone that's going to implement them. If you had a working prototype
 attached as a patch (or as a branch on github/bitbucket), then it might be
 worth keeping this ticket open for reference purposes. However, at the
 moment, it's the seed of a vague idea and nothing more. We try to keep
 Trac a list of clearly actionable items, not vague open ended dreams and
 aspirations.

 If you think this idea is worth pursuing, then follow the instructions in
 the [https://docs.djangoproject.com/en/1.3/internals/contributing/
 contributing guide], and start a discussion on django-developers.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13223: ValueError with inline and save as new

2011-08-02 Thread Django

#13223: ValueError with inline and save as new
-+-
   Reporter: |  Owner:  gptvnt
  lucalenardi| Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.1|   Keywords:  admin, save-as-new
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Andrew Macgregor ):

 * cc: andrew@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16559: Switch to entity-manager type system.

2011-08-02 Thread Django

#16559: Switch to entity-manager type system.
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone:  2.0|  Component:  Uncategorized
  Version:  1.3-rc1|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 I realize that I am submitting this ticket as anonymous, which will give
 it reduced credibility, but at least consider the logic posted here, and
 before you close this ticket, state your reason and give me time to reply.
 All I am trying to do here is implement a change, that in my opinion, will
 make django closer to your design philosophies.

 This suggestion is mostly based on the "SQL efficiency" philosophy.

 Instead of using Model.save(), you should change the framework to
 implement a entity-manager approach, [http://www.doctrine-
 project.org/docs/orm/2.0/en/reference/introduction.html#mini-tutorial like
 doctrine does]. This would allow a one-time SQL calculation, providing
 maximum efficiency. Instead of running an SQL query for each changed
 model, only one query would be needed for all of them.

 I realize this would be a BIG change to implement; I would recommend it
 for a major release version. However, this would make django more perfect
 in regard to the design philosophies, also writing less Model.save() calls
 and only one em.flush() call. I hope you seriously consider this change
 instead of just blowing it off; I think it would be very beneficial to
 django.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16557: Tutorial 1.0 Docs

2011-08-02 Thread Django

#16557: Tutorial 1.0 Docs
-+---
   Reporter:  mike@… |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by russellm):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 For future reference -- the ticket tracker isn't for asking questions,
 it's for tracking known bugs and issues in Django's code. Questions should
 be directed to django-users.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16555: admin css / static content wasn't loading

2011-08-02 Thread Django

#16555: admin css / static content wasn't loading
-+-
   Reporter: |  Owner:  nobody
  leotreasure@…  | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  invalid|Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 If you're running the tutorial as described, you shouldn't need to run
 collectstatic. The built-in runserver will serve static media from exactly
 the same sources that collectstatic will generate them. The only reason
 you would need to run collectstatic is:

  1. You're running the tutorial code through a full web server, not the
 development server
  2. You've missed a step in the tutorial.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16554: Unnecessary join when using a reverse foreign-key relationship in separate filter or aggregate calls

2011-08-02 Thread Django

#16554: Unnecessary join when using a reverse foreign-key relationship in 
separate
filter or aggregate calls
-+-
   Reporter: |  Owner:  nobody
  bendavis78 | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This is working as designed.

 A single filter() clause is used to determine the join-sharing
 relationships in a query; Model.objects.filter(Q1, Q2) is not
 *necessarily* equivalent to Model.objects.filter(Q1).filter(Q2).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16558: django.contrib.humanize filters are not well localized

2011-08-02 Thread Django

#16558: django.contrib.humanize filters are not well localized
---+---
 Reporter:  blackraven |  Owner:  blackraven
 Type:  Bug| Status:  new
Milestone:  1.4|  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords:  russian, humanize  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 In some countries (namely, Russia), "decimal point" is actually comma, and
 thousands separator is space (as comma used as decimal part separator!).
 This needs to be fixed in humanize filters, as they are useless in ru
 locale right now.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

2011-08-02 Thread Django

#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.3|  Component:  Forms
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  sprintdec01
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carbonXT):

 * cc: mike@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16557: Tutorial 1.0 Docs

2011-08-02 Thread Django

#16557: Tutorial 1.0 Docs
-+---
   Reporter:  mike@… |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by mike@…):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I think i see it now that i've drilled down a bit that this is the field's
 label.. maybe make mention of it as such in the docs where it is being
 entered in?  I see it as part of rendered html on the second page.  Sorry
 for bothering you with this, love what i've seen so far <3.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16557: Tutorial 1.0 Docs

2011-08-02 Thread Django

#16557: Tutorial 1.0 Docs
---+---
 Reporter:  mike@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 I'm somewhat ''new'' to Django and Python in general but have some
 experience with ORMs.. I'm wondering about the line in
 https://docs.djangoproject.com/en/1.3/intro/tutorial01/ marked with '***'
 below:

 {{{
 from django.db import models

 class Poll(models.Model):
 question = models.CharField(max_length=200)
 ***pub_date = models.DateTimeField('date published')

 class Choice(models.Model):
 poll = models.ForeignKey(Poll)
 choice = models.CharField(max_length=200)
 votes = models.IntegerField()
 }}}

 Why is the argument passed to DateTimeField() 'date published', is that an
 easy name of the field?  When I looked at DateTimeField() documentation at
 
https://docs.djangoproject.com/en/1.3/ref/models/fields/#django.db.models.DateTimeField
 I see:

 {{{
 class DateTimeField([auto_now=False, auto_now_add=False, **options])
 }}}

 also the generated SQL made no mention of the string "date published" in a
 comment or otherwise:

 {{{
 BEGIN;
 CREATE TABLE "polls_poll" (
 "id" serial NOT NULL PRIMARY KEY,
 "question" varchar(200) NOT NULL,
 "pub_date" timestamp with time zone NOT NULL
 );
 CREATE TABLE "polls_choice" (
 "id" serial NOT NULL PRIMARY KEY,
 "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"),
 "choice" varchar(200) NOT NULL,
 "votes" integer NOT NULL
 );
 COMMIT;
 }}}

 I'm not sure what `**options` is so that might be the magic I'm looking
 for.  I'm just saying that as someone looking at these docs for the first
 time, having `pub_date = models.DateTimeField('date published')` in there
 is confusing for someone who is trying to get an idea of what the
 framework is doing.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14049: Fixture loading should be skipped for TestCase decorated with @skip*

2011-08-02 Thread Django

#14049: Fixture loading should be skipped for TestCase decorated with @skip*
-+-
   Reporter:  zimnyx |  Owner:  PaulM
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ramiro):

 In [16579]:
 {{{
 #!CommitTicketReference repository="" revision="16579"
 Fixed #16372 -- Changed strategy implemented in r16369 to fix #14049 to
 avoid affecting the statistics of test cases ran/skipped kept by unittest.
 Thanks zimnyx for the report.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16372: TransactionTestCase doesn't count skipped cases in test result.

2011-08-02 Thread Django

#16372: TransactionTestCase doesn't count skipped cases in test result.
+---
   Reporter:  zimnyx|  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by ramiro):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16579]:
 {{{
 #!CommitTicketReference repository="" revision="16579"
 Fixed #16372 -- Changed strategy implemented in r16369 to fix #14049 to
 avoid affecting the statistics of test cases ran/skipped kept by unittest.
 Thanks zimnyx for the report.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16579 - django/trunk/django/test

2011-08-02 Thread noreply

Author: ramiro
Date: 2011-08-02 15:30:26 -0700 (Tue, 02 Aug 2011)
New Revision: 16579

Modified:
   django/trunk/django/test/testcases.py
Log:
Fixed #16372 -- Changed strategy implemented in r16369 to fix #14049 to avoid 
affecting the statistics of test cases ran/skipped kept by unittest. Thanks 
zimnyx for the report.

Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2011-08-01 23:38:11 UTC (rev 
16578)
+++ django/trunk/django/test/testcases.py   2011-08-02 22:30:26 UTC (rev 
16579)
@@ -283,28 +283,27 @@
 include a call to super().setUp().
 """
 testMethod = getattr(self, self._testMethodName)
-if (getattr(self.__class__, "__unittest_skip__", False) or
-getattr(testMethod, "__unittest_skip__", False)):
-return
+skipped = (getattr(self.__class__, "__unittest_skip__", False) or
+getattr(testMethod, "__unittest_skip__", False))
 
-self.client = self.client_class()
-try:
-self._pre_setup()
-except (KeyboardInterrupt, SystemExit):
-raise
-except Exception:
-import sys
-result.addError(self, sys.exc_info())
-return
+if not skipped:
+self.client = self.client_class()
+try:
+self._pre_setup()
+except (KeyboardInterrupt, SystemExit):
+raise
+except Exception:
+result.addError(self, sys.exc_info())
+return
 super(TransactionTestCase, self).__call__(result)
-try:
-self._post_teardown()
-except (KeyboardInterrupt, SystemExit):
-raise
-except Exception:
-import sys
-result.addError(self, sys.exc_info())
-return
+if not skipped:
+try:
+self._post_teardown()
+except (KeyboardInterrupt, SystemExit):
+raise
+except Exception:
+result.addError(self, sys.exc_info())
+return
 
 def _post_teardown(self):
 """ Performs any post-test things. This includes:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16537: layermapping spatial ref check not checking against alternate DB

2011-08-02 Thread Django

#16537: layermapping spatial ref check not checking against alternate DB
-+
   Reporter:  shifflett.shane@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  GIS
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+

Comment (by aaugustin):

 #16556 was a duplicate.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16556: django.contrib.gis.utils.srs fails to preserve database when creating SpatialRefSys querysets

2011-08-02 Thread Django

#16556: django.contrib.gis.utils.srs fails to preserve database when creating
SpatialRefSys querysets
-+
   Reporter:  anonymous  |  Owner:  jbronn
   Type:  Bug| Status:  closed
  Milestone:  1.4|  Component:  GIS
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
Changes (by aaugustin):

 * status:  assigned => closed
 * resolution:   => duplicate


Comment:

 This is a duplicate of #16537. Please search before opening a new ticket —
 here, it's completely trivial to find the duplicate:
 https://code.djangoproject.com/search?q=SpatialRefSys&noquickjump=1&ticket=on

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16556: django.contrib.gis.utils.srs fails to preserve database when creating SpatialRefSys querysets

2011-08-02 Thread Django

#16556: django.contrib.gis.utils.srs fails to preserve database when creating
SpatialRefSys querysets
-+--
   Reporter:  anonymous  |  Owner:  jbronn
   Type:  Bug| Status:  assigned
  Milestone:  1.4|  Component:  GIS
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
Changes (by jbronn):

 * status:  new => assigned
 * owner:  chander.ganesan@… => jbronn
 * stage:  Unreviewed => Accepted
 * milestone:   => 1.4


Old description:

> django.contrib.gis.utils.srs fails to preserve database when creating
> SpatialRefSys querysets
>
> Currently, the code (line ~70 or so) reads like this:
>
> # Creating the spatial_ref_sys model.
> try:
> # Try getting via SRID only, because using all kwargs may
> # differ from exact wkt/proj in database.
> sr = SpatialRefSys.objects.get(srid=srs.srid)
> except SpatialRefSys.DoesNotExist:
> sr = SpatialRefSys.objects.create(**kwargs)
>
> It should read like this:
>

> # Creating the spatial_ref_sys model.
> try:
> # Try getting via SRID only, because using all kwargs may
> # differ from exact wkt/proj in database.
> sr = SpatialRefSys.objects.using(database).get(srid=srs.srid)
> except SpatialRefSys.DoesNotExist:
> sr = SpatialRefSys.objects.using(database).create(**kwargs)
>

> Otherwise support for multiple backends is sort of broken.

New description:

 `django.contrib.gis.utils.srs` fails to preserve database when creating
 `SpatialRefSys` querysets

 Currently, the code (line ~70 or so) reads like this:
 {{{
 #!python

 # Creating the spatial_ref_sys model.
 try:
 # Try getting via SRID only, because using all kwargs may
 # differ from exact wkt/proj in database.
 sr = SpatialRefSys.objects.get(srid=srs.srid)
 except SpatialRefSys.DoesNotExist:
 sr = SpatialRefSys.objects.create(**kwargs)
 }}}

 It should read like this:
 {{{
 #!python

 # Creating the spatial_ref_sys model.
 try:
 # Try getting via SRID only, because using all kwargs may
 # differ from exact wkt/proj in database.
 sr = SpatialRefSys.objects.using(database).get(srid=srs.srid)
 except SpatialRefSys.DoesNotExist:
 sr = SpatialRefSys.objects.using(database).create(**kwargs)
 }}}

 Otherwise support for multiple backends is sort of broken.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16556: django.contrib.gis.utils.srs fails to preserve database when creating SpatialRefSys querysets

2011-08-02 Thread Django

#16556: django.contrib.gis.utils.srs fails to preserve database when creating
SpatialRefSys querysets
--+---
   Reporter:  anonymous   |  Owner:  chander.ganesan@…
   Type:  Bug | Status:  new
  Milestone:  |  Component:  GIS
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Ugh.  Basically, the '.using()' method needs to be used when creating the
 SpatialRefSys query set.  sorry for the poor formatting.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16556: django.contrib.gis.utils.srs fails to preserve database when creating SpatialRefSys querysets

2011-08-02 Thread Django

#16556: django.contrib.gis.utils.srs fails to preserve database when creating
SpatialRefSys querysets
---+---
 Reporter:  anonymous  |  Owner:  chander.ganesan@…
 Type:  Bug| Status:  new
Milestone: |  Component:  GIS
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 django.contrib.gis.utils.srs fails to preserve database when creating
 SpatialRefSys querysets

 Currently, the code (line ~70 or so) reads like this:

 # Creating the spatial_ref_sys model.
 try:
 # Try getting via SRID only, because using all kwargs may
 # differ from exact wkt/proj in database.
 sr = SpatialRefSys.objects.get(srid=srs.srid)
 except SpatialRefSys.DoesNotExist:
 sr = SpatialRefSys.objects.create(**kwargs)

 It should read like this:


 # Creating the spatial_ref_sys model.
 try:
 # Try getting via SRID only, because using all kwargs may
 # differ from exact wkt/proj in database.
 sr = SpatialRefSys.objects.using(database).get(srid=srs.srid)
 except SpatialRefSys.DoesNotExist:
 sr = SpatialRefSys.objects.using(database).create(**kwargs)


 Otherwise support for multiple backends is sort of broken.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16555: admin css / static content wasn't loading

2011-08-02 Thread Django

#16555: admin css / static content wasn't loading
-+-
   Reporter: |  Owner:  nobody
  leotreasure@…  | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ramiro):

 Just to be sure: What version of Django were you using when you followed
 the tutorial? What version of the tutorial did you follow?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16555: admin css / static content wasn't loading

2011-08-02 Thread Django

#16555: admin css / static content wasn't loading
-+-
   Reporter: |  Owner:  nobody
  leotreasure@…  | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by leotreasure@…):

 I realise I've used the dev tutorial link however both 1.3 and dev
 tutorials look similar, so I recommend changes be submitted to both
 versions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16555: admin css / static content wasn't loading

2011-08-02 Thread Django

#16555: admin css / static content wasn't loading
-+-
   Reporter: |  Owner:  nobody
  leotreasure@…  | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16555: admin css / static content wasn't loading

2011-08-02 Thread Django

#16555: admin css / static content wasn't loading
--+---
 Reporter:  leotreasure@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 Hi,

 Following this [https://docs.djangoproject.com/en/dev/intro/tutorial02/]
 lead me to an admin page with no css styling. I mucked around for about an
 hour before working it out.

 I asked on the IRC channel and was recommended this page
 [https://docs.djangoproject.com/en/1.3/howto/static-files/] where I found
 the solution.

 My suggestion is to add these steps onto the tutorial02 website:
 set the STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic" to your
 mysite static folder in settings.py
 and
 Run the collectstatic management command:
 ./manage.py collectstatic

 Regards,

 Leo

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5579: Trac activation mail is sent from 'webmaster@localhost'

2011-08-02 Thread Django

#5579: Trac activation mail is sent from 'webmaster@localhost'
-+-
   Reporter:  tback  |  Owner:  anonymous
   Type: | Status:  closed
  Uncategorized  |  Component:  Djangoproject.com
  Milestone: |  Web site
Version: |   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:  activation email
   Triage Stage:  Accepted   |  trac
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by fclail@…):

 * ui_ux:   => 0


Comment:

 Seen this contact site listed on the Gary Clail website, and was wondering
 if I could get 'follow up' comments I made in 2002 deleted? Thanksin
 advance? Frances C.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16554: Unnecessary join when using a reverse foreign-key relationship in separate filter or aggregate calls

2011-08-02 Thread Django

#16554: Unnecessary join when using a reverse foreign-key relationship in 
separate
filter or aggregate calls
+--
 Reporter:  bendavis78  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  SVN |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+--
 Django allows you to perform queries across reverse foreign key
 relationships.  If, however, you need to access that same relationship in
 more than one filter or aggregate call, the ORM creates unnecessary joins.

 == Example ==

 app/models.py:
 {{{#!python
 class Author(models.Model):
 first_name = models.CharField(max_length=30)
 last_name = models.CharField(max_length=30)
 email = models.EmailField()

 class Book(models.Model):
 author = models.ForeignKey(Author, related_name='books')
 title = models.CharField(max_length=100)
 genre = models.CharField(max_length=20, choices=(
 ('SCIFI', 'SciFi'),
 ('FANTASY', 'Fantasy'),
 ('NONFICTION', 'NonFiction')
 ))
 published = models.DateField()
 pages = models.IntegerField()
 }}}

 This particular query will only perform one join on app_books:
 {{{#!python
 qs = Author.objects.filter(books__genre='SCIFI', books__pages__gt=500)
 print qs.query
 }}}
 {{{#!sql
 SELECT "app_author"."id", "app_author"."first_name",
 "app_author"."last_name", "app_author"."email"
 FROM "app_author"
 INNER JOIN "app_book" ON ("app_author"."id" = "app_book"."author_id")
 WHERE ("app_book"."genre" = 'SCIFI'  AND "app_book"."pages" > 500 )
 }}}

 However, if you separate the filter() call into two separate calls, you
 get this:
 {{{#!python
 qs = Author.objects.filter(books__genre='SCIFI')
 qs = qs.filter(books__pages__gt=500)
 print qs.query
 }}}
 {{{#!sql
 SELECT "app_author"."id", "app_author"."first_name",
 "app_author"."last_name", "app_author"."email"
 FROM "app_author"
 INNER JOIN "app_book" ON ("app_author"."id" = "app_book"."author_id")
 INNER JOIN "app_book" T3 ON ("app_author"."id" = T3."author_id")
 WHERE ("app_book"."genre" = 'SCIFI'  AND T3."pages" > 500 )
 }}}
 As you can see, simply separating out the filters into separate calls
 creates a new, completely unecessary join.

 This also occurs if you need to do an aggregate:
 {{{#!python
 qs = Author.objects.annotate(pages_written=Sum('books__pages'))
 qs = qs.filter(books__genre='SCIFI')
 print qs.query
 }}}
 {{{#!sql
 SELECT "app_author"."id", "app_author"."first_name",
 "app_author"."last_name", "app_author"."email", SUM("app_book"."pages") AS
 "pages_written"
 FROM "app_author"
 LEFT OUTER JOIN "app_book" ON ("app_author"."id" = "app_book"."author_id")
 INNER JOIN "app_book" T3 ON ("app_author"."id" = T3."author_id")
 WHERE T3."genre" = 'SCIFI'
 GROUP BY "app_author"."id", "app_author"."first_name",
 "app_author"."last_name", "app_author"."email"
 }}}
 In this particular case, I imagine the ORM is seeing the need for two
 joins because one is outer and one is inner, however, I would argue that
 if an outer join already occurs as a result of an aggregate, it should
 always use the existing join.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15149: Memcached backend: possible issue with cache keys

2011-08-02 Thread Django

#15149: Memcached backend: possible issue with cache keys
+-
   Reporter:  jeff@…|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Cache system)
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  memcached
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by jeff@…):

 No, I've never figured it out.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15775: Can't enter scientific notation in decimal fields

2011-08-02 Thread Django

#15775: Can't enter scientific notation in decimal fields
+---
   Reporter:  gregthe1  |  Owner:  brunogola
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Forms
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by anonymous):

 Sorry, disregard my last comment.  I was using the wrong version.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15775: Can't enter scientific notation in decimal fields

2011-08-02 Thread Django

#15775: Can't enter scientific notation in decimal fields
+---
   Reporter:  gregthe1  |  Owner:  brunogola
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Forms
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by anonymous):

 I still don't think this is correct.  Using the patch, it doesn't work for
 1E+4.


 {{{
 >>> f = DecimalField(max_digits=10, decimal_places=1)
 >>> f.validate(Decimal('1E+4'))
 Traceback (most recent call last):
 ...
 ValidationError: [u'Ensure that there are no more than 1 decimal places.']
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16553: GeoIP unicode problem

2011-08-02 Thread Django

#16553: GeoIP unicode problem
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.2|   Severity:  Normal
 Keywords:  geoip unicode  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 Here is the full traceback when GeoIP returns unicode characters in city
 name and this is passed to template:

 {{{
 Traceback (most recent call last):

   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py",
 line 100, in get_response
 response = callback(request, *callback_args, **callback_kwargs)

   File "/home/test/main/index/views.py", line 18, in index
 return render_to_response("index.html", {"request": request, "geoip":
 gp})

   File "/usr/lib/python2.5/site-packages/django/shortcuts/__init__.py",
 line 20, in render_to_response
 return HttpResponse(loader.render_to_string(*args, **kwargs),
 **httpresponse_kwargs)

   File "/usr/lib/python2.5/site-packages/django/template/loader.py", line
 186, in render_to_string
 return t.render(context_instance)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 173, in render
 return self._render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 167, in _render
 return self.nodelist.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 796, in render
 bits.append(self.render_node(node, context))

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 809, in render_node
 return node.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py",
 line 125, in render
 return compiled_parent._render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 167, in _render
 return self.nodelist.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 796, in render
 bits.append(self.render_node(node, context))

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 809, in render_node
 return node.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py",
 line 62, in render
 result = block.nodelist.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 796, in render
 bits.append(self.render_node(node, context))

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 809, in render_node
 return node.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py",
 line 258, in render
 return self.nodelist_true.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 796, in render
 bits.append(self.render_node(node, context))

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 809, in render_node
 return node.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py",
 line 258, in render
 return self.nodelist_true.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 796, in render
 bits.append(self.render_node(node, context))

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 809, in render_node
 return node.render(context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 849, in render
 return _render_value_in_context(output, context)

   File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
 line 829, in _render_value_in_context
 value = force_unicode(value)

   File "/usr/lib/python2.5/site-packages/django/utils/encoding.py", line
 88, in force_unicode
 raise DjangoUnicodeDecodeError(s, *e.args)

 DjangoUnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-8:
 invalid data. You passed in 'Hlubok\xe1 Nad Vltavou' ()

 }}}

 complete code:

 {{{
 gp = None
 g = GeoIP()
 ip = request.META.get("REMOTE_ADDR", None)
 if ip:
 gp = g.city(ip)
 return render_to_response("index.html", {"request": request, "geoip": gp})

 }}}

 Django 1.2.4

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16552: Missing app in Django admin dependency list.

2011-08-02 Thread Django

#16552: Missing app in Django admin dependency list.
--+---
   Reporter:  zelo|  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Documentation
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by anonymous):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 It look like this: "Admin has three dependencies - django.contrib.auth,
 django.contrib.contenttypes and django.contrib.messages. If these
 applications are not in your INSTALLED_APPS list, add them."

 And it should contain django.contrib.sessions. Becouse without that it
 doesn't work.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16552: Missing app in Django admin dependency list.

2011-08-02 Thread Django

#16552: Missing app in Django admin dependency list.
--+---
 Reporter:  zelo  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 Under following link is wrong information about django admin dependencies.
 https://docs.djangoproject.com/en/dev/ref/contrib/admin/#overview

 It look like this:
 Admin has three dependencies - django.contrib.auth,
 django.contrib.contenttypes and django.contrib.messages. If these
 applications are not in your INSTALLED_APPS list, add them.
 And it should contain django.contrib.sessions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16551: After upgrading from 1.1 to 1.3 readonly_fields fails

2011-08-02 Thread Django

#16551: After upgrading from 1.1 to 1.3 readonly_fields fails
-+---
   Reporter:  bojsen@…   |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution:  worksforme |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+---
Changes (by anonymous):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => worksforme
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 They work for me. Without more information than what's provided here it's
 hard to speculate what may be causing the behavior you are seeing.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16117: Provide decorators to easily mark functions/methods as list_display items or admin actions

2011-08-02 Thread Django

#16117: Provide decorators to easily mark functions/methods as list_display 
items
or admin actions
---+---
   Reporter:  haras|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  contrib.admin
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by velmont):

 * ui_ux:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16536: inspectdb with numerical column names

2011-08-02 Thread Django

#16536: inspectdb with numerical column names
-+-
   Reporter: |  Owner:  teraom
  danodonovan| Status:  assigned
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  inspectdb
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by teraom):

 1. Is the usage of isdigit() correct here? I assume there will be no
 period in the column name.
 2. Should I use unicode.isnumeric() instead?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16551: After upgrading from 1.1 to 1.3 readonly_fields fails

2011-08-02 Thread Django

#16551: After upgrading from 1.1 to 1.3 readonly_fields fails
---+---
 Reporter:  bojsen@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  contrib.admin
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+---
 Instead of the DB value the field itself is outputted:


 {{{
 {'help_text': u'', 'field': 'triggered', 'name': 'triggered', 'label':
 'triggered'}
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django should load custom SQL when testing

2011-08-02 Thread Django

#16550: Django should load custom SQL when testing
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  closed
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 If my solution isn't viable, because it introduces an inconsistency
 between the way tables work during a test case and the way they work in
 production, then that is already the case, isn't it? In production the
 custom SQL is loaded. In testing it is not. That's a pretty big
 inconsistency right there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django should load custom SQL when testing

2011-08-02 Thread Django

#16550: Django should load custom SQL when testing
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  closed
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 No, the limitation isn't moronic. As I have now said *twice*, it exists
 *for a very good reason*.

 The solution you propose isn't viable because it introduces an
 inconsistency between the way tables work during a test case and the way
 they work in production. Essentially, you're suggesting that whenever I
 have a test that utilizes the table with raw SQL modifications/inserts, I
 need to remember that it also needs the custom_types sql to be defined.
 This is a pretty egregious violation of DRY.

 The only real solution to this that I can see was alluded to in the
 discussion on #14661 -- that is, introducing a type of custom SQL that can
 be used for DDL modifications. However, what I *haven't* seen is an
 elegant way to introduce this feature.

 Please don't reopen this ticket again. If you feel strongly about this
 idea, take it to django-developers for discussion.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16536: inspectdb with numerical column names

2011-08-02 Thread Django

#16536: inspectdb with numerical column names
-+-
   Reporter: |  Owner:  teraom
  danodonovan| Status:  assigned
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  inspectdb
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by teraom):

 * status:  new => assigned
 * owner:  nobody => teraom


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django should load custom SQL when testing

2011-08-02 Thread Django

#16550: Django should load custom SQL when testing
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  reopened
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by elver.loho@…):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 Having to work around this deliberate limitation is moronic, not the core
 devs.

 Here is my proposal for how it should be implemented:

 {{{
 #!div style="font-size: 80%"
 Workable version:
   {{{#!python
 class CustomModelObjects(TestCase):

 sql = ["custom_types.sql"]
 fixtures = ["test_data.json"]

 def testQuantityWeight__mul__PricePerUnit__Normal(self):
 qw = QuantityWeight(15, "t")
 ppu = PricePerUnit(PriceWithCurrency(100, "EUR"), "t")
 pwc = qw * ppu
 self.failUnlessEqual(pwc, PriceWithCurrency(1500, "EUR"))
   }}}
 }}}

 The stuff in sql is always loaded before the test runs. Since this is a
 new feature, you can easily document that it CANNOT be used for loading
 custom data. If you know to put that line there, you've probably read the
 docs and already know this. Problem solved without any workarounds.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django should load custom SQL when testing

2011-08-02 Thread Django

#16550: Django should load custom SQL when testing
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  closed
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Well, calling the core devs moronic is an interesting way to get your
 feature implemented for you. :-)

 Allow me to assure you that the limitation exists for a very good reason.
 If you got to the trouble of reading the links that I provided, you should
 even be able to work out what that reason is. I will also direct your
 attention to #14661.

 Essentially, we are in a situation where the feature that you are
 requesting is not possible to implement without causing other problems.
 Unless you have a *specific* proposal for how to avoid those problems,
 this is a wontfix.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django should load custom SQL when testing (was: Django fails to load custom SQL when running tests)

2011-08-02 Thread Django

#16550: Django should load custom SQL when testing
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  reopened
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by elver.loho@…):

 * status:  closed => reopened
 * type:  Bug => New feature
 * resolution:  wontfix =>


Comment:

 In that case I request this as a feature. It is downright moronic that I
 have to work around Django's deliberate limitation in order to test more
 advanced code.

 I said this before and will repeat it here: I am NOT using SQL to load
 data into the database before testing. I am using SQL to create custom
 data types in the database before I can even load my data in it. Fixtures
 DO NOT help me in any way when trying to solve this problem. I am not
 putting data into the database -- I am extending the capabilities of the
 database.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16550: Django fails to load custom SQL when running tests

2011-08-02 Thread Django

#16550: Django fails to load custom SQL when running tests
-+-
   Reporter: |  Owner:  nobody
  elver.loho@…   | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 This is a documented limitation of Django's test setup. See
 [https://docs.djangoproject.com/en/1.3/topics/testing/#fixture-loading the
 documentation on testing] and
 [https://docs.djangoproject.com/en/1.3/releases/1.2.5/#use-of-custom-sql-
 to-load-initial-data-in-tests the release notes where this change was
 introduced] for an explanation why.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

41 matches

Mail list logo