Nabble - django-developers

Re: Ticket #8425 and USStateField (again)

2009-12-24T03:22:40Z

On Thu, Dec 24, 2009 at 4:49 PM, James Bennett <ubernostrum@...> wrote:
> On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
> <freakboy3742@...> wrote:
>> I could live with either approach existing in the codebase. I won't
>> express a preference, though - I'll leave the decision of which
>> approach is preferable to those that will actually have to use it.
>
> Honestly, given both the controversy which prompted the original
> change and the varying real-world needs, I think the two-field
> solution is more appropriate:

My concern with having two fields is that it introduces a false
dichotomy. There aren't just 2 options here - potentially any
permutation of the following list is possible:

Lower 48
DC
AK + HI
US Protectorates
US Military Drops

So as soon as you introduce a USPostalField that includes all of
these, I guarantee that someone will ask for a field that has all the
choices *except* the US Military drops, and then someone will find
some reason to why Guam should be on the list, but the American
Marianas shouldn't, until eventually you have a dozen US*Field fields.

The reason this discussion is happening in the first place is that we
couldn't come up with a single set of options that would keep everyone
happy. Increasing the number of options to 2 decreases the number of
disparate groups by 1 - but that doesn't mean we're left with 2
disparate groups.

Adopting USStateField(choices=POSTAL_REGIONS) or
USStateField(lower_48=True, ...) means that end users can mix and
match whatever combinations they need - we provide a single field, and
let them mix whatever combination of options they want.

Yours,
Russ Magee %-)

--

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

Re: Ticket #8425 and USStateField (again)

2009-12-24T03:08:47Z

On Thu, Dec 24, 2009 at 3:30 PM, Richard Laager <rlaager@...> wrote:
> On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote:
>> This is completely backwards compatible as long as we keep
>> "STATE_CHOICES" to the same subset that exists today.
>
> Yikes, that's really restrictive. You want that list to remain static
> until Django 2.0?

No - I want the list of choices that currently contains the lower 48 +
HI, AK and DC to be called STATE_CHOICES - just like it is now - for
the forseeable future. For other uses, we can provide other helpful
groupings, like POSTAL_REGIONS (which contains anything USPS
recognizes); then, the user can choose
USStateField(choices=POSTAL_REGIONS) and get an extended set of
options.

> I ask because the Canadian province list includes *incorrect*
> abbreviations, which we discovered when trying to do a simple
> state/province choices form field.

If this is the case, then it is a bug, which should be logged and fixed.

I'm not saying we shouldn't fix bugs, or that state lists must be
fixed for all time. What I'm saying that any Django-based project that
is currently deployed using and uses USStateField is currently
rejecting Puerto Rico and American Armed Forces Middle East. These
project should continue to operate as-is without the need for any code
changes on the part of the developer. What we *can* do is open up
options that make it easy for a developer to opt into allowing other
regions as acceptable to USStateField.

Yours,
Russ Magee %-)

--

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

Re: Ticket #8425 and USStateField (again)

2009-12-24T00:49:04Z

On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee
<freakboy3742@...> wrote:
> I could live with either approach existing in the codebase. I won't
> express a preference, though - I'll leave the decision of which
> approach is preferable to those that will actually have to use it.

Honestly, given both the controversy which prompted the original
change and the varying real-world needs, I think the two-field
solution is more appropriate:

One field -- USStateField -- should only do things which are actually
US states, plus the District of Columbia. Throw in a flag which
defaults to False and which restricts it to the 48 contiguous states +
DC. This avoids the political upheaval because it doesn't include
anything exotic or "not really US" like territories, protectorates,
COFA nations. It also provides for a couple extremely common use
cases: companies which will do business with you only if you're in an
actual US state, and companies which will do business with you only if
you're in the "lower 48".

The other field -- USPostalCodeField -- should accept any abbreviation
the US Post Office accepts. This allows the broader use case of
shipping to anywhere the Post Office can handle, and also lines up
with the abbreviations used for data reported by the US federal
government.

The actual sets of choices can be built up as you've described, or in
some other fashion (I don't particularly care, but would lean toward
breaking them into logical sets so people can do more fine-grained
stuff if they want).

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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

Re: Ticket #8425 and USStateField (again)

2009-12-23T23:30:15Z

On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote:
> This is completely backwards compatible as long as we keep
> "STATE_CHOICES" to the same subset that exists today.

Yikes, that's really restrictive. You want that list to remain static
until Django 2.0?

I ask because the Canadian province list includes *incorrect*
abbreviations, which we discovered when trying to do a simple
state/province choices form field.

Richard

signature.asc (204 bytes) Download Attachment

Re: Ticket #8425 and USStateField (again)

2009-12-23T19:44:48Z

On Wed, Dec 23, 2009 at 1:29 AM, James Bennett <ubernostrum@...> wrote:

> I've previously brought up some issues with the removal of certain
> options from the choices on localflavor's USStateField[1] as a result
> of ticket #8425[2] and, with feature freeze for 1.2 approaching and
> perhaps more time soon to be available for such things, I'd like to
> call attention to it again since it just bit me pretty hard.
>
> Real-world use case: I'm importing data from a feed provided by the US
> Centers for Disease Control. The data's classified according to state
> and region (using the US Department of Health and Human Services'
> standard regional breakdown[3]), and so for parts of it I'm using a
> USStateField.
>
> But HHS and CDC -- like the US Post Office and every other US federal
> agency, considers Palau, the Marshall Islands and the Federated States
> of Micronesia to be valid "US" areas for data-gathering and reporting
> purposes. And this causes a data importer based on USStateField to
> required ugly workarounds, since those are not valid choices for the
> field.
>
> Any chance of getting the choices fixed so we can actually make use of
> USStateField with this sort of data?

I'm +1 to fixing this general mess. The thread you pointed to contains
two workable solutions that I can see:

1) Ship a bunch of state subsets:

LOWER_48 = (...)
NON_CONTIGUOUS = (hi, ak)
PROTECTORATES = (...)
MILITARY_DROPS = (...)

STATE_CHOICES = LOWER_48 + NON_CONTIGUOUS
USPS_SERVICE = US_STATES + NON_CONTIGUOUS + PROTECTORATES + MILITARY_DROPS

This is completely backwards compatible as long as we keep
"STATE_CHOICES" to the same subset that exists today. It's a little
more fiddly to use, but it's completely consistent with every other
choice-based field in Django.

2) Given that this there is a limited collection of subsets, expose
these specific choices as booleans on the USStateField definition:

USStateField(lower_48=True, non_contiguous=True, military_drops=False, ...)

This is also backwards compatible, as long as the default values in
the field definition match the currently available choices. It's
explicit and easy to use, but it does leave the question of what to do
if you specify choices=[..] AND you tweak the state parameters (at a
guess, manually specified choices trumps flags).

I could live with either approach existing in the codebase. I won't
express a preference, though - I'll leave the decision of which
approach is preferable to those that will actually have to use it.

Yours,
Russ Magee %-)

--

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

Re: 1.2 Feature freeze

2009-12-23T17:39:17Z

A bit late, but here's my update to GSoC-1 (admin-ui). My branch is in good shape, but tests are sparse and docs are nonexistant. Two more weeks is enough time for me to get the following done:

1) Moooooar tests

2) Merge with trunk

3) Split out each feature into individual patches and throw them in trac

4) Docs for each feature

Thanks a lot for pushing the date.

Regards,

Zain

On Wed, Dec 23, 2009 at 12:34 AM, James Bennett <ubernostrum@...> wrote:

Technically, the major feature freeze for Django 1.2 was to have
happened sometime yesterday, US Central time. As of this moment, we're
not actually frozen, but will be as soon as I hear status reports on
the following (high-priority features which have not yet listed a
commit on the 1.2 features page):

* GSoC-1 (admin UI)
* CSoC-2 (WSGI improvements)
* GSoC-4 (model validation)
* GSoC-6 (test improvements)
* Templates-4 (tag loading improvements)
* URLs-1 (get_absolute_url replacement)
* Views-1 (class-based generic views)

If you're one of the people involved with one of the above features,
you need to get me a status update as soon as humanly possible,
preferably in one of two forms:

1. "The code's ready and I'll check it in as soon as I finish writing
this email to you", or
2. "The code's not ready, guess it'll wait for 1.3"

If the status update consists of "it's checked in but nobody updated
the 1.2 features page", you will be slapped with a large trout.

(in case y'all can't tell, I have no plans to let 1.2 slip like 1.1 did...)

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@....
To unsubscribe from this group, send email to django-developers%2Bunsubscribe@....
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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 Feature freeze

2009-12-23T17:28:17Z

Since it appears there are some people who have code ready but have
time constraints due to holidays, I'm going to (by release-manager
fiat, unless Adrian or Jacob want something else) plan 1.2 alpha (and
corresponding major feature freeze) for Tuesday, January 5. Any major
feature not in trunk by then doesn't make 1.2.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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

Re: 1.2 Feature freeze

2009-12-23T07:59:27Z

On Wed, Dec 23, 2009 at 2:34 AM, James Bennett <ubernostrum@...> wrote:
> Technically, the major feature freeze for Django 1.2 was to have
> happened sometime yesterday, US Central time. As of this moment, we're
> not actually frozen, but will be as soon as I hear status reports on
> the following (high-priority features which have not yet listed a
> commit on the 1.2 features page):
>

[snip]

> * GSoC-4 (model validation)

I'd like to get this in. I have a current diff on my laptop that I'm
going to review again on the plane this afternoon, but I don't think
there's any development work that it needs. Merging the changes from
multidb into the branch might take some effort, but I think Honza is
willing to do that if we commit the branch to trunk.

I'm going to have questionable internet connectivity until Monday, but
if I can get online I'd like to check this in in the next couple of
days. (I will have access to email on my phone though, so I'll watch
this thread.) I don't want to break the schedule, but it'd be a shame
to let this slip to 1.3.

Joseph

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 Feature freeze

2009-12-23T06:50:03Z

Hi everybody,

model-validation patch hasn't changed since September (except merges
with trunk) basically, there is one outstanding issue (#12078) that I
can fix over the holidays. Also a merge with current trunk needs to be
done because of the huge changes in the past few days.

I have both time and resources to get the patch the next day or two,
what I don't have is:

* ANY feedback on the actual code. Is the code ok? What is missing?
What should I change?

* commit bit so I need somebody to work with me here. Joseph has been
busy it seems.

Will somebody please step up and tell me what I have to work on to get
it committed or, better yet, do the actual commit?

Thanks!

Honza Král
E-Mail: Honza.Kral@...
Phone: +420 606 678585

On Wed, Dec 23, 2009 at 2:33 PM, Karen Tracey <kmtracey@...> wrote:

> I'm listed as one of the interested committers on GSoC-6 (test
> improvements). Unfortunately I have not had time to devote to moving that
> along, and so far as I know nobody else has either -- I have not seen any
> activity or patches or discussion that would indicate anyone was hoping to
> get something done on it for the 1.2 feature freeze. So at this point I
> think it will have to wait for 1.3. (If I'm wrong and there is someone out
> there hoping to get something in by yesterday, please speak up...but I'm not
> going to have any time to look at anything related to it for at least a
> week, so unless there's another committer who can help with it, I think it's
> too late for it to make 1.2.)
>
> 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@....
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@....
> 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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Which textmate django bundle?

2009-12-23T05:48:24Z

VIM. django-dev is for discussion of developing Django itself!

zweb schrieb:

> I see there are multiple django bundles for textmate.
>
> Which is the best one you recommend?
>
> --
>
> 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@....
> To unsubscribe from this group, send email to django-developers+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>
>

Re: 1.2 Feature freeze

2009-12-23T05:33:51Z

I'm listed as one of the interested committers on GSoC-6 (test improvements). Unfortunately I have not had time to devote to moving that along, and so far as I know nobody else has either -- I have not seen any activity or patches or discussion that would indicate anyone was hoping to get something done on it for the 1.2 feature freeze. So at this point I think it will have to wait for 1.3. (If I'm wrong and there is someone out there hoping to get something in by yesterday, please speak up...but I'm not going to have any time to look at anything related to it for at least a week, so unless there's another committer who can help with it, I think it's too late for it to make 1.2.)

Karen

Re: Add querystring helper methods to Page class

2009-12-23T03:37:05Z

2009/12/22 Ben Spaulding <ben.spaulding@...>:
> I have created a patch that would allow for something much simpler, like so:
>
> <a href="?{{ page.next_page_querystring }}">Next page</a>

This is what I do in my own homemade paginators. It works well.

> Though there has been much talk of creating template tags which would
> produce all-out pagination bars, I believe this particular
> functionality should be an actual method on the page object for two
> reasons:
>
> 1. This is basic functionality whose end result is hard to dispute
> (as opposed to a full pagination bar where markup and features could
> be disputed eternally),

Actual full pagination-bars could be shipped around as templates,
whether to be used in inclusion-tags or included directly. No need to
lock ourselves to the one, true pagination-style.

HM

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 Feature freeze

2009-12-23T02:16:11Z

On Dec 23, 8:34 am, James Bennett <ubernost...@...> wrote:
> * URLs-1 (get_absolute_url replacement)

The code's not ready - I have the get_url / get_url_path methods but I
don't have a good enough hold yet on what actually needs to be done to
replace the existing get_absolute_url behaviour and all of it's
idiosyncrasies.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

2009-12-23T01:04:11Z

On Wed, Dec 23, 2009 at 1:32 PM, Michael Manfre <mmanfre@...> wrote:
> With multiple database defined, what is the expected behavior for
> syncdb and the other db related commands?

The management commands all work the same way under multidb - they
only ever work on a single database at a time. If you don't specify a
database, the 'default' databse is used.

> The documentation shows that
> it is relatively easy to associate an admin form with a given
> database, but is there a way of associated a model or app to a given
> database?

Yes - ish. If you're working with your own application and models,
just define a custom manager for that model. The manager just needs to
override get_query_set() and applies a using() modifier:

class PersonManager(models.Manager):
def get_query_set(self):
return super(PersonManager, self).get_query_set().using('other')

class Person(models.Model):
objects = PersonManager()
name = models.CharField(max_length=50)
...

Unfortunately, this approach doesn't work for a model in a reusable
app - for example, you can't easily push contrib.auth.User to a
different database. However, you can just call
User.objects.using('other').... whenever you want to use the User
model.

I know this is less than ideal, but the goal for 1.2 was to complete
the plumbing and get the important porcelain in place (e.g., using()).
The goal for 1.3 is to identify the common end-user use cases for
multidb and make some easily exploitable hooks for end-users.

Yours,
Russ Magee %-)

--

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

1.2 Feature freeze

2009-12-23T00:34:39Z

Technically, the major feature freeze for Django 1.2 was to have
happened sometime yesterday, US Central time. As of this moment, we're
not actually frozen, but will be as soon as I hear status reports on
the following (high-priority features which have not yet listed a
commit on the 1.2 features page):

* GSoC-1 (admin UI)
* CSoC-2 (WSGI improvements)
* GSoC-4 (model validation)
* GSoC-6 (test improvements)
* Templates-4 (tag loading improvements)
* URLs-1 (get_absolute_url replacement)
* Views-1 (class-based generic views)

If you're one of the people involved with one of the above features,
you need to get me a status update as soon as humanly possible,
preferably in one of two forms:

1. "The code's ready and I'll check it in as soon as I finish writing
this email to you", or
2. "The code's not ready, guess it'll wait for 1.3"

If the status update consists of "it's checked in but nobody updated
the 1.2 features page", you will be slapped with a large trout.

(in case y'all can't tell, I have no plans to let 1.2 slip like 1.1 did...)

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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

Which textmate django bundle?

2009-12-22T21:49:06Z

I see there are multiple django bundles for textmate.

Which is the best one you recommend?

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

2009-12-22T21:32:23Z

With multiple database defined, what is the expected behavior for
syncdb and the other db related commands? The documentation shows that
it is relatively easy to associate an admin form with a given
database, but is there a way of associated a model or app to a given
database?

Regards,
Michael Manfre

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

2009-12-22T20:58:06Z

On Tue, Dec 22, 2009 at 4:55 PM, Brett Hoerner <brett@...> wrote:

On Dec 22, 4:27 pm, Russell Keith-Magee <freakboy3...@...>
wrote:

> * Allow TEST_NAME=None to mean "don't try and instantiate this
> database in test mode"

That sounds good, too.

If I was using the slaving part of multi-db i'd be very likely to write some internal code that made it so if you tried to save (alter) an object retrieved from a slave it'd either 1) log a nasty error message or 2) raise an exception. If this approach was used, I would be unable to write any kind of unit test against code that depended on stuff coming from a [master /] slave.

Unfortunately, I don't have a better suggestion at this time.

Craig

Re: Final call for feedback: Multi-db

2009-12-22T16:55:19Z

On Dec 22, 4:27 pm, Russell Keith-Magee <freakboy3...@...>
wrote:
> * Allow TEST_NAME=None to mean "don't try and instantiate this
> database in test mode"

That sounds good, too.

> * Allow a top level TEST_DATABASES setting; TEST_DATABASES would
> override DATABASES; if TEST_DATABASES isn't defined, then TEST_NAME
> would be used.

This would have to function differently than the current DATABASES
setting, though, right? Otherwise I don't see how the same problem
would be avoided ('default' and 'read_slave' both point the same
physical DB).

> I'll need to cogitate on this over my Christmas pudding :-) Any other
> suggestions welcome.

Awesome, thanks much.

Brett

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Final call for feedback: Multi-db

2009-12-22T16:27:25Z

On Wed, Dec 23, 2009 at 7:06 AM, Brett Hoerner <brett@...> wrote:

> On Dec 19, 6:48 am, Russell Keith-Magee <freakboy3...@...>
> wrote:
>> You're right - read slaves are an intended common use case
>
> I know the branch landed but I'd like to mention another issue
> regarding read-slaves, hope that's OK. :)
>
> Running tests against code that uses master and read-slaves (but
> actually point at the same exact DB while testing) is currently not
> possible. When the tests begin each DB is expected to be started fresh
> (the runner stops if it cannot), so you can't use the same DB name/
> host for two entries in settings.DATABASES. I think it's awfully
> common for people not develop with *actual* read-slaves on their local
> machine, but rather to use the abstractions available and point their
> "read-slave" at the same information as their default DB.
>
> I could just set TEST_NAME for the read-slave to something else, but
> in our production code and tests (as an example) we'll have some test
> inserting data on master and another using it via a read-slave.
> Unless I'm missing something, we'd have to create all data on both the
> master and read-slaves in order to test properly, which is awfully
> awkward and possibly confusing.
>
> Any thoughts? Off the top of my head all I can think of is that the
> test setup could check if any DBs match up in name/host and not try to
> drop/create after the first.

Hrm... interesting problem. In addition to your name-matching
approach, I can think of two approaches off the top of my head:

* Allow TEST_NAME=None to mean "don't try and instantiate this
database in test mode"

* Allow a top level TEST_DATABASES setting; TEST_DATABASES would
override DATABASES; if TEST_DATABASES isn't defined, then TEST_NAME
would be used.

I'll need to cogitate on this over my Christmas pudding :-) Any other
suggestions welcome.

Yours,
Russ Magee %-)

--

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

Re: Final call for feedback: Multi-db

2009-12-22T15:06:15Z

On Dec 19, 6:48 am, Russell Keith-Magee <freakboy3...@...>
wrote:
> You're right - read slaves are an intended common use case

I know the branch landed but I'd like to mention another issue
regarding read-slaves, hope that's OK. :)

Running tests against code that uses master and read-slaves (but
actually point at the same exact DB while testing) is currently not
possible. When the tests begin each DB is expected to be started fresh
(the runner stops if it cannot), so you can't use the same DB name/
host for two entries in settings.DATABASES. I think it's awfully
common for people not develop with *actual* read-slaves on their local
machine, but rather to use the abstractions available and point their
"read-slave" at the same information as their default DB.

I could just set TEST_NAME for the read-slave to something else, but
in our production code and tests (as an example) we'll have some test
inserting data on master and another using it via a read-slave.
Unless I'm missing something, we'd have to create all data on both the
master and read-slaves in order to test properly, which is awfully
awkward and possibly confusing.

Any thoughts? Off the top of my head all I can think of is that the
test setup could check if any DBs match up in name/host and not try to
drop/create after the first.

Thanks,
Brett

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Call for feedback: django.utils.signed and signed cookies

2009-12-22T13:08:15Z

Am 22.12.2009 um 08:20 schrieb Simon Willison:

> On Dec 22, 12:52 am, Johannes Dollinger
> <johannes.dollin...@...> wrote:
>> I'd like some more kwargs to Signer and TimestampSigner. Mostly
>> what's
>> inhttp://dpaste.com/136418/(except the `separator` kwarg, which was
>> a bad idea as it depends on encode()): Signer(serializer=...) and
>> TimestampSigner(ttl=...).
>
> The first few versions of the code had a bunch more stuff along the
> lines of that dpaste (which expires in 6 days, so here's a gist copy
> of it: http://gist.github.com/261572 )

Thanks.

> After struggling with it for quite a while, I decided that having a
> single class that handled signing, serialization and compression
> wasn't the right approach - it was doing far too much. Instead, I
> changed the design so the Signer's only responsibility was generating
> signatures, appending them to strings and verifying that they were
> correct. The encryption/serialization was extracted out and moved
> directly in to the signed.dumps() and signed.loads() functions.
>
> This solved a bunch of problems I was having with the code - too many
> subclasses, confusing amounts of multiple inheritance for mixing
> together different subclassed behaviours - and generally made
> everything feel a lot more cohesive.
>
> That's also why I added the BACKEND setting for setting a cookie
> signing backend - that way, users with specific ideas about how their
> signed cookies should work can write their own class that does pretty
> much anything they like.
>
> Is there any functionality in particular that you think should be
> resurrected from the more-complex-signing-classes? I'm very keen on
> keeping the serialization and compression stuff out of Signer.

I wanted to proposed to make dumps() and loads() methods on Signer
again. Now they are bound to TimestampSigner. If they were defined as
methods, you could reuse the functionality on subclasses. A mixin
might be overengineering as you would never use it without Signer and
it makes sense to have the feature available for all subclasses. Why
do you want to keep it out?

Useful additions:
* If sign() and unsign() take a `sep` kwarg, Signer.__init__() should
also take it. Better yet, only set it in __init__().
* TimestampSigner.__init__() needs a max_age/ttl kwarg.
__
Johannes

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Add querystring helper methods to Page class

2009-12-22T13:08:01Z

A ticket has already been created for this, but SmileyChris
recommended I bring the issue up here.

Working with pagination and query strings within a template can be
painful. Personally, I have never had a situation when I was
paginating using a GET parameter where there were not other parameters
that needed to be preserved through out the various pages.

Take search, for example. There may be parameters for searching within
one or more models, for a particular author and sorting by date.
Maintaining all of these parameters within the pagination links takes
some serious template logic.

{# Linebreaks added for readability. In real life this would need to
be one, long line. #}
<a href="?{% for key, values in request.GET.iterlists %}
{% ifnotequal key "page" %}
{% for value in values %}
{{ key }}={{ value }}&
{% endfor %}
{% endifnotequal %}
{% endfor %}page={{ page.next_page_number }}">Next page</a>

That kind of logic shouldn’t be in a template. I have created a patch
that would allow for something much simpler, like so:

<a href="?{{ page.next_page_querystring }}">Next page</a>

Though there has been much talk of creating template tags which would
produce all-out pagination bars, I believe this particular
functionality should be an actual method on the page object for two
reasons:

1. This is basic functionality whose end result is hard to dispute
(as opposed to a full pagination bar where markup and features could
be disputed eternally),
2. This does not require the request context processor to be
installed.

Note that this patch includes documentation. Tests are still needed. I
am not married to the exact implementation, but I and others I have
discussed this and feel that this simplicity and functionality belong
in Django’s pagination.

Ticket: http://code.djangoproject.com/ticket/10941
Patch: http://code.djangoproject.com/attachment/ticket/10941/querystring-methods.diff

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Call for feedback: django.utils.signed and signed cookies

2009-12-22T13:01:35Z

Having talked to James about this I'm holding off on the commit until
we've had it reviewed by real cryptographers. I'll aim to get it in
before the 1.2 beta feature freeze.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Congratulations Alex and Russell on committing multidb!

2009-12-22T13:00:26Z

... and congratulations to Marc Garcia and Jannis Leidel for the i18n/
l10n improvements that just went in as well. Also congratulations to
everyone for the other awesome commits going in at the moment. There
are far too many congratulations to spell them all out at the moment
(with hindsight I wish I hadn't started!).

1.2 is going to rock.

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Congratulations Alex and Russell on committing multidb!

2009-12-22T12:55:46Z

On Tue, Dec 22, 2009 at 2:44 PM, Peter <kmpm@...> wrote:

>
> I just noticed and can only agree... nice work.
>
> //Peter
>
> On Tue, Dec 22, 2009 at 18:27, Simon Willison <simon@...>
> wrote:
>>
>> And a big congratulations to all involved. Here's the changeset log
>> (on GitHub since Trac seems not to like being linked to at the
>> moment):
>>
>>
>> http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611
>>
>> And here's the documentation:
>>
>> http://docs.djangoproject.com/en/dev/topics/db/multi-db/
>>
>> Really excited about this - can't wait to start putting it to good
>> use.
>>
>> Cheers,
>>
>> Simon
>>
>> --
>>
>> 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@....
>> To unsubscribe from this group, send email to
>> django-developers+unsubscribe@....
>> 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@....
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@....
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Thanks guys, there are a lot more people than Russ and I who deserve
the credit though!

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

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

Re: Congratulations Alex and Russell on committing multidb!

2009-12-22T12:44:28Z

I just noticed and can only agree... nice work.

//Peter

On Tue, Dec 22, 2009 at 18:27, Simon Willison <simon@...> wrote:

And a big congratulations to all involved. Here's the changeset log
(on GitHub since Trac seems not to like being linked to at the
moment):

http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611

And here's the documentation:

http://docs.djangoproject.com/en/dev/topics/db/multi-db/

Really excited about this - can't wait to start putting it to good
use.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Bug #11017: Oracle LIKEC query doesn't use index

2009-12-22T12:00:28Z

On Tue, Dec 22, 2009 at 12:58 AM, Jani Tiainen <redetin@...> wrote:

> Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in
> patchset 9.2.0.6 and any later version.
>
> What comes to Oracle official support options for 9.2:
> Premier Support Ends: 31-Jul-2007
> Extended Support Ends: 30-Jul-2010
>
> If any problem is encountered you're first required to upgrade to latest
> patchset (9.2.0.8) before requesting further assistance from Oracle. And
> Oracle has always advised to apply patchsets to db.
>
> I have only 9.2.0.1, but bug should appear there and I've patchsets for
> 9.2.0.6 and up so I can see does it really happen after upgrade. I can
> stage and run tests to see was it that or something else.
>
> And known workaround (that works "everywhere") is use one I pasted few
> ticket comment before.
>
> It's more like design and support decision here - is there need to
> support (obsolete) Oracle version(s)?

Hi Jani,

The only thing I need before committing the workaround is for somebody
to verify that the bug in #5985 is reproducible in version 9.2.0.5 or
earlier, and that the workaround indeed fixes it. Since I don't have
an instance with the appropriate patchset available to test it myself,
I'd appreciate it if you would do that testing.

I for one don't see a compelling case for dropping support for Oracle
9 yet. If the workaround is successful, then the only Django feature
currently not supported for Oracle 9 is the regex filter, and I'm not
aware of anything on the horizon that will change that. Oracle shops
also tend to be notoriously slow at updating. My employer is not as
bad as some, but even we still have some Django installations running
on Oracle 9.

Even if we do decide to drop support for Oracle 9 (or just the early
patchsets thereof) soon, it will take a full release cycle so that we
can issue the appropriate deprecation warnings. We'll still want to
be using the workaround at least for the short term.

Ian

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Oracle backend TextField unique=True error

2009-12-22T09:32:01Z

On Dec 22, 2009, at 12:04 AM, Mario Briggs wrote:

> Hi Ian,
>
> Ian Kelly wrote:
>> Not currently, no. And if I were to put in some work on improving on
>> the Oracle backend's support for filtering on TextFields, I would
>> concentrate first on fixing the query so that it correctly compares
>> the entire TextField and not just the first 4000 characters.
>> Unfortunately, I don't think any function-based index will help with
>> that.
>
> hmmm. I am thinking differently. I think most of these use-cases where
> someone is doing a value based look up on a 'Text' would be a
> situation similar to what Russ has in admin view - the type is not
> fixed, it is could be any one of the types. However it is definetly
> not 'length unlimited' and the modeler has a fair idea of what the
> broad upper limit would be.
>
> I think if it is really length-unlimited, then automatically there
> shouldnt be a use-case to do a value based lookup or have a unique
> index for it (unless it is once in a blue-moon, anything really
> frequent and performance will not be usable). Definetly there could
> be a valid need for a google-style search of the column and this is
> where DB2 and Oracle support 'Text' indexing of LOB columns.
>
> Peter, maybe you can elaborate why you choose 'Text' and why you need
> an a unique index on it.
>

I chose TextField in order to store long LDAP DN strings. At my place of work, our LDAP has quite a bit of depth in the tree, and OU and CN names can be quite long, which result in some very long strings to store. I could conceivably use a CharField with an extremely large max_length, say 1024 or 2048, but with TextField I don't need to worry about overrunning the max length.

The LDAPGroup model itself is a mapping between an LDAP OU group membership, and a django.contrib.auth.models.Group, used to associate a given Django group and the permissions assigned to it with any LDAP-authenticating user who belongs to the OU. When an LDAP user logs in, their LDAP group memberships are checked. If one of those groups is mapped to a Django group, then their Django user model is automatically assigned to the mapped Django group, thereby giving the user whatever access rights are assigned to the group.

I marked the TextField unique in order to ensure that there is one and only one mapping instance per LDAP OU. The LDAPGroup mapping instance can map a single LDAP OU to multiple Django Groups, but I wanted to make sure there was only one such mapping in order to avoid having to search through multiple mapping instances to find all the places where an OU might be used. In this case, there's only one mapping per OU.

The system would work if I used CharField, but I might run into cases where the OU is longer than the max_length on the CharField. The system would also work if I relaxed the unique constraint on the OU, but then the database table would have redundancies.

I realize I'm somewhat abusing the notion of a TextField at the database level. In this case, I want to treat it like an unlimited length varchar. Or, the mirror perspective, I want to be able to guarantee uniqueness of a CLOB. I hadn't thought much about the limitations in Oracle's treatment of CLOBs, since I'm using Postgres myself, where this works.

---Peter

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Ticket #8425 and USStateField (again)

2009-12-22T09:29:07Z

I've previously brought up some issues with the removal of certain
options from the choices on localflavor's USStateField[1] as a result
of ticket #8425[2] and, with feature freeze for 1.2 approaching and
perhaps more time soon to be available for such things, I'd like to
call attention to it again since it just bit me pretty hard.

Real-world use case: I'm importing data from a feed provided by the US
Centers for Disease Control. The data's classified according to state
and region (using the US Department of Health and Human Services'
standard regional breakdown[3]), and so for parts of it I'm using a
USStateField.

But HHS and CDC -- like the US Post Office and every other US federal
agency, considers Palau, the Marshall Islands and the Federated States
of Micronesia to be valid "US" areas for data-gathering and reporting
purposes. And this causes a data importer based on USStateField to
required ugly workarounds, since those are not valid choices for the
field.

Any chance of getting the choices fixed so we can actually make use of
USStateField with this sort of data?

[1] http://groups.google.com/group/django-developers/browse_thread/thread/6b896421e63b6f9e/
[2] http://code.djangoproject.com/ticket/8425
[3] http://www.hhs.gov/about/regionmap.html

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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

Congratulations Alex and Russell on committing multidb!

2009-12-22T09:27:41Z

And a big congratulations to all involved. Here's the changeset log
(on GitHub since Trac seems not to like being linked to at the
moment):

http://github.com/django/django/commit/836d297e68d6a63103780295adebf6eaf6779611

And here's the documentation:

http://docs.djangoproject.com/en/dev/topics/db/multi-db/

Really excited about this - can't wait to start putting it to good
use.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Model translation

2009-12-22T04:01:57Z

As Russell said, this is probably a bad time, but I thought I'd throw
in some quick notes nonetheless.

> '''django-modeltranslation''': I think this general approach is the way to go

I agree that it's probably the best alternative available currently,
but still not without significant drawbacks (like breaking when fields/
fieldsets are used in the ModelAdmin, and not being able to
transparently query on translated fields - an issue you later
mentioned). We're running a severely hacked private version/fork of
django-modeltranslation in production, having added fields/fieldsets
and some custom jQuery/CSS admin widgetry, but in no form that would
be ready for public consumption, let alone as a basis for inclusion in
Django core.

Also, I was about to say that the development of django-
modeltranslation seems essentially stalled, but then checked to see
that the first update since March (support for admin inlines) was made
three days ago, so scratch that ;-)

However. I'm in the conceptual planning stages of a fresh solution to
the model translation problem, one that I hesitate to say anything
more about at this time since the ideas involved are not yet fully
formed in my head. When Django 1.2 hits bugfix-only mode, I'll
probably start tracking trunk and doing some initial prototyping
against it. If it amounts to anything, you'll hear more about it next
spring, hopefully around the timeframe that Russ talked about (3-4
months or so). Absolutely, positively no promises, though.
Procrastinating endlessly and losing motivation altogether are a
distinct possibility :-). But still, if and when the discussion pops
up again later on, I might have some ideas and/or code to share.

Until then.

- JK Laiho

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Call for feedback: django.utils.signed and signed cookies

2009-12-22T02:06:17Z

On Dec 22, 6:22 am, Russell Keith-Magee <freakboy3...@...>
wrote:
> As far as the patch itself is concerned, looks good to me. My only
> other request would be a serving of dogfood - if we're going to
> include a signed cookie module, it would be nice to prove that it can
> actually be used by actually using it.

I'd love to see the cookie backend of the new django.contrib.messages
feature switch over to using get/set_signed_cookie. I'm happy to put
together the patch, or alternatively one of the people who worked on
that feature can do it.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Bug #11017: Oracle LIKEC query doesn't use index

2009-12-21T23:58:18Z

Escaping bug exists in Oracle 9.2.0.5 and earlier. It was fixed in
patchset 9.2.0.6 and any later version.

What comes to Oracle official support options for 9.2:
Premier Support Ends: 31-Jul-2007
Extended Support Ends: 30-Jul-2010

If any problem is encountered you're first required to upgrade to latest
patchset (9.2.0.8) before requesting further assistance from Oracle. And
Oracle has always advised to apply patchsets to db.

I have only 9.2.0.1, but bug should appear there and I've patchsets for
9.2.0.6 and up so I can see does it really happen after upgrade. I can
stage and run tests to see was it that or something else.

And known workaround (that works "everywhere") is use one I pasted few
ticket comment before.

It's more like design and support decision here - is there need to
support (obsolete) Oracle version(s)?

--

Jani Tiainen

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Re: Call for feedback: django.utils.signed and signed cookies

2009-12-21T23:20:15Z

On Dec 22, 12:52 am, Johannes Dollinger
<johannes.dollin...@...> wrote:
> I'd like some more kwargs to Signer and TimestampSigner. Mostly what's
> inhttp://dpaste.com/136418/(except the `separator` kwarg, which was
> a bad idea as it depends on encode()): Signer(serializer=...) and
> TimestampSigner(ttl=...).

The first few versions of the code had a bunch more stuff along the
lines of that dpaste (which expires in 6 days, so here's a gist copy
of it: http://gist.github.com/261572 )

After struggling with it for quite a while, I decided that having a
single class that handled signing, serialization and compression
wasn't the right approach - it was doing far too much. Instead, I
changed the design so the Signer's only responsibility was generating
signatures, appending them to strings and verifying that they were
correct. The encryption/serialization was extracted out and moved
directly in to the signed.dumps() and signed.loads() functions.

This solved a bunch of problems I was having with the code - too many
subclasses, confusing amounts of multiple inheritance for mixing
together different subclassed behaviours - and generally made
everything feel a lot more cohesive.

That's also why I added the BACKEND setting for setting a cookie
signing backend - that way, users with specific ideas about how their
signed cookies should work can write their own class that does pretty
much anything they like.

Is there any functionality in particular that you think should be
resurrected from the more-complex-signing-classes? I'm very keen on
keeping the serialization and compression stuff out of Signer.

Cheers,

Simon

--

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@....
To unsubscribe from this group, send email to django-developers+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.