Re: Problem with history view in admin page

2009-11-25 Thread Russell Keith-Magee
On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov  wrote:
> Hi Russell,
>
> is it possible to introduce some new field type
> ShortTextField for that purpose, that will be by default
> `varchar(4000)` on Oracle and DB2 who supports long varchars, and
> `text` on other backends like it was before, excepting 'smalltext'
> instead of 'longtext' for mysql?

I can see that this approach doesn't have any backward compatibility
issues. However, from a documentation point of view, explaining the
difference between a ShortTextField and a TextField requires a leaky
abstraction (i.e., you have to know about implementation details in
order for the explanation to make sense).

With a different coat of paint, it might be more palatable. A name
like ShortTextField presupposes the storage implementation, but tells
you nothing about the appropriate usage. However, a different name -
something like GenericKeyField tells you nothing about the storage,
but does tell you  when it might be appropriate to use it.

Of course GenericKeyField has the problem of being easy to confuse
with GenericForeignKey. For that reason, I'm not sold on
GenericKeyField as a name - any suggestions in this general vein are
welcome.

> I think this is a point where "TextField is accessed by value"
> abstraction breaks, and better separation between long string and
> referenced object should be introduced.

Agreed.

> I assume we have not much Oracle & DB2 users yet, and nothing will
> change for them unless they already suffer from this problem and they
> will not anymore. Migration script is single "alter table" command,
> and that needs to be documented.

I'm always a little nervous about upgrading instructions, and doubly
so about those that include database migrations. History has shown us
that it doesn't matter how well we write upgrading notes - backwards
incompatible changes cause problems. Unless there is a particularly
compelling reason to change the existing Oracle implementation, I'd
rather not force that change.

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




Re: Oracle/GIS Testers Needed

2009-11-25 Thread Alex Gaynor
On Thu, Nov 26, 2009 at 1:42 AM, Jani Tiainen  wrote:
> On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:
>
>>
>> Thanks for taking the time to run all of those!  All of those
>> ConnectionDoesNotExist errors come from the fact that the multidb
>> tests expect you to have more than 1 DB set up in your settings file,
>> the rigth solution here is probably to just fail right away, instead
>> of attempting to run each individual test which can produce some
>> confusing failures.  As for the other errors I'm not sure what's a
>> consequence of my work, and what's an existing condition.  If you
>> could run the trunk tests (with your modification for memory) and see
>> what the result is that would be awesome.  Any new errors are
>> obviously regressions and should be fixed.
>>
>> Alex
>>
>
> I didn't have to run anything, that what computers are for..? :)
>
> Could you provide sample DATABASES connection definition for multidb
> tests so I could rerun all that fancy stuff correctly.
>
> --
>
> 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-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

DATABASES = {
"default": {
# your settings here
},
"other": {
"ENGINE": "sqlite3",
"NAME": ":memory:",
}
}

Is all you need (don't bother rerunning all of the tests with these
settings, the only ones affected are the multiple_database ones).

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




Re: Oracle/GIS Testers Needed

2009-11-25 Thread Jani Tiainen
On Thu, 2009-11-26 at 01:28 -0600, Alex Gaynor wrote:

> 
> Thanks for taking the time to run all of those!  All of those
> ConnectionDoesNotExist errors come from the fact that the multidb
> tests expect you to have more than 1 DB set up in your settings file,
> the rigth solution here is probably to just fail right away, instead
> of attempting to run each individual test which can produce some
> confusing failures.  As for the other errors I'm not sure what's a
> consequence of my work, and what's an existing condition.  If you
> could run the trunk tests (with your modification for memory) and see
> what the result is that would be awesome.  Any new errors are
> obviously regressions and should be fixed.
> 
> Alex
> 

I didn't have to run anything, that what computers are for..? :)

Could you provide sample DATABASES connection definition for multidb
tests so I could rerun all that fancy stuff correctly.

-- 

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




Re: Oracle/GIS Testers Needed

2009-11-25 Thread Alex Gaynor
On Thu, Nov 26, 2009 at 1:21 AM, Jani Tiainen  wrote:
> On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
>> Hey all,
>>
>> Russ and I have been working on getting the multi-db work ready for
>> merge (final stretch here hopefully!), and I just ported the Oracle
>> backend to the slightly updated backend arcitecture so it could use
>> some testers.  If you've got an Oracle setup and can run some tests
>> that would be great.  You can grab the code here:
>>
>> http://github.com/alex/django/tree/multiple-db
>>
>> Make sure you use the multiple-db branch.  I understand running the
>> tests under Oracle can be a bit slow, so perhaps start by just running
>> the "queries" tests, if they fail please reply with the complete
>> tracebacks and such here, otherwise if you have the time a shot at
>> running the full test suite would be great.
>>
>
> I did ran full test suite. First at maximum tablespace size must be
> set bit over 100MB (I changed it to 200MB but in tests I had peak of
> 102MB)
>
> And then bunch of interesting errors:
>
> ==
> ERROR: Multi-db fixtures are loaded correctly
> --
> Traceback (most recent call last):
>  File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 467, in test_fixture_loading
>    title="Pro Django"
>  File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
>    callableObj(*args, **kwargs)
>  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 300, in get
>    num = len(clone)
>  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 77, in __len__
>    self._result_cache = list(self.iterator())
>  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 234, in iterator
>    compiler = self.query.get_compiler(using=self.db)
>  File "/home/jtiai/src/django/multidb/django/db/models/sql/query.py",
> line 148, in get_compiler
>    connection = connections[using]
>  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 68, in __getitem__
>    self.ensure_defaults(alias)
>  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 54, in ensure_defaults
>    raise ConnectionDoesNotExist("The connection %s doesn't exist" %
> alias)
> ConnectionDoesNotExist: The connection other doesn't exist
>
> ==
> ERROR: Queries are constrained to a single database
> --
> Traceback (most recent call last):
>  File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 100, in test_basic_queries
>    published=datetime.date(2009, 5, 4))
>  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 315, in create
>    obj.save(force_insert=True, using=self.db)
>  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
> line 429, in save
>    self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
>  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
> line 442, in save_base
>    connection = connections[using]
>  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 68, in __getitem__
>    self.ensure_defaults(alias)
>  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
> 54, in ensure_defaults
>    raise ConnectionDoesNotExist("The connection %s doesn't exist" %
> alias)
> ConnectionDoesNotExist: The connection other doesn't exist
>
> ==
> ERROR: Objects created on the default database don't leak onto other
> databases
> --
> Traceback (most recent call last):
>  File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 34, in test_default_creation
>    Book.objects.get(title="Pro Django")
>  File "/home/jtiai/src/django/multidb/django/db/models/manager.py",
> line 119, in get
>    return self.get_query_set().get(*args, **kwargs)
>  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
> line 307, in get
>    % (self.model._meta.object_name, num, kwargs))
> MultipleObjectsReturned: get() returned more than one Book -- it
> returned 2! Lookup parameters were {'title': 'Pro Django'}
>
> ==
> ERROR: Operations that involve sharing FK objects across databases
> raise an error
> --
> Traceback (most recent call last):
>  File
> "/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
> line 391, in test_foreign_key_cross_database_protection
>    published=datetime.date(2009, 5, 4))
>  File 

Re: Oracle/GIS Testers Needed

2009-11-25 Thread Jani Tiainen
On Fri, 2009-11-20 at 01:14 -0500, Alex Gaynor wrote:
> Hey all,
> 
> Russ and I have been working on getting the multi-db work ready for
> merge (final stretch here hopefully!), and I just ported the Oracle
> backend to the slightly updated backend arcitecture so it could use
> some testers.  If you've got an Oracle setup and can run some tests
> that would be great.  You can grab the code here:
> 
> http://github.com/alex/django/tree/multiple-db
> 
> Make sure you use the multiple-db branch.  I understand running the
> tests under Oracle can be a bit slow, so perhaps start by just running
> the "queries" tests, if they fail please reply with the complete
> tracebacks and such here, otherwise if you have the time a shot at
> running the full test suite would be great.
> 

I did ran full test suite. First at maximum tablespace size must be 
set bit over 100MB (I changed it to 200MB but in tests I had peak of
102MB)

And then bunch of interesting errors:

==
ERROR: Multi-db fixtures are loaded correctly
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 467, in test_fixture_loading
title="Pro Django"
  File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
callableObj(*args, **kwargs)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 300, in get
num = len(clone)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 77, in __len__
self._result_cache = list(self.iterator())
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 234, in iterator
compiler = self.query.get_compiler(using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/sql/query.py",
line 148, in get_compiler
connection = connections[using]
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
68, in __getitem__
self.ensure_defaults(alias)
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
54, in ensure_defaults
raise ConnectionDoesNotExist("The connection %s doesn't exist" %
alias)
ConnectionDoesNotExist: The connection other doesn't exist

==
ERROR: Queries are constrained to a single database
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 100, in test_basic_queries
published=datetime.date(2009, 5, 4))
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 315, in create
obj.save(force_insert=True, using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 429, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 442, in save_base
connection = connections[using]
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
68, in __getitem__
self.ensure_defaults(alias)
  File "/home/jtiai/src/django/multidb/django/db/utils.py", line
54, in ensure_defaults
raise ConnectionDoesNotExist("The connection %s doesn't exist" %
alias)
ConnectionDoesNotExist: The connection other doesn't exist

==
ERROR: Objects created on the default database don't leak onto other
databases
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 34, in test_default_creation
Book.objects.get(title="Pro Django")
  File "/home/jtiai/src/django/multidb/django/db/models/manager.py",
line 119, in get
return self.get_query_set().get(*args, **kwargs)
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 307, in get
% (self.model._meta.object_name, num, kwargs))
MultipleObjectsReturned: get() returned more than one Book -- it
returned 2! Lookup parameters were {'title': 'Pro Django'}

==
ERROR: Operations that involve sharing FK objects across databases
raise an error
--
Traceback (most recent call last):
  File
"/home/jtiai/src/django/multidb/tests/regressiontests/multiple_database/tests.py",
line 391, in test_foreign_key_cross_database_protection
published=datetime.date(2009, 5, 4))
  File "/home/jtiai/src/django/multidb/django/db/models/query.py",
line 315, in create
obj.save(force_insert=True, using=self.db)
  File "/home/jtiai/src/django/multidb/django/db/models/base.py",
line 429, in save
self.save_base(using=using, 

Re: Feedback on ticket 7777

2009-11-25 Thread thebitguru
OK, you have me convinced :)  My assumption was that the developer
changing these options would take the time to ensure that the database
supports it, but I can see why one might assume that if the API
supports it then the database probably does too.  I will do a survey
of the django supported databases to see which support the two cases.

I hope you feel better (from the cold, that is :)).

- Farhan

On Nov 26, 12:09 am, Russell Keith-Magee 
wrote:
> On Thu, Nov 26, 2009 at 1:52 PM, thebitguru  wrote:
> > Thanks for the reply, Russ.
>
> > I need to revise the patch, but I need some confirmation.  I am not
> > sure if it is worth determining what all the different databases
> > support. I think optional parameters (allow_{inf,nan}=False) that let
> > the user specify that django should allow these two cases would be
> > sufficient.  Note that I am suggesting setting these to False, which
> > will break compatibility, but I believe that this is really what the
> > average user is expecting anyways.
>
> How could it break compatibility? From my testing (i.e., running your
> test cases), passing in NaN or Inf raises exceptions at the moment. At
> this point, it's impossible for any patch dealing with Inf and NaN to
> break backwards compatibility, because there is no working baseline
> behavior.
>
> > If I can get a confirmation that this behavior will be acceptable then
> > I will go ahead and submit an updated patch that reflects this
> > change.  This time I will ping again in one week :)
>
> Adding a configuration doesn't always solve a problem. More often than
> not, it adds a new problem. This is one of those cases.
>
> Putting a choice in the hands of a user which can come back and bite
> them is not in the style of Django. Defining a DecimalField with
> allow_inf=True will cause errors if you use a Postgres database. I'm
> not about to commit code that will allow you to have a valid Django
> configuration that throws errors in production.
>
> This is why a survey of the current level of support in databases is
> important. If, for example, no database supports Inf, then there is no
> reason to even have an allow_inf setting. If support is varied, then
> we need to have a discussion about the right way to handle the
> variation.
>
> There is also the issue of good API design to consider. From a
> practical standpoint, I'm having difficulty thinking of a reason why
> allow_nan needs to exist - why should an end user be allowed to submit
> as a form value that is, a priori, known to be invalid? Essentially,
> you're allowing the user to submit "divide by zero" as a valid form
> value - what is the use case for this?
>
> In summary, the process goes like this:
>  1. Get the API right
>  2. Implement it.
>
> We're still on step 1. :-)
>
> > Enjoy the thanksgiving,
>
> Thanks, but FYI: Thanksgiving on the last Thursday in November is a
> US-only holiday. It's held on other dates in some countries, and not
> at all in others. Australia doesn't celebrate Thanksgiving at all.
>
> 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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




Re: Feedback on ticket 7777

2009-11-25 Thread Russell Keith-Magee
On Thu, Nov 26, 2009 at 1:52 PM, thebitguru  wrote:
> Thanks for the reply, Russ.
>
> I need to revise the patch, but I need some confirmation.  I am not
> sure if it is worth determining what all the different databases
> support. I think optional parameters (allow_{inf,nan}=False) that let
> the user specify that django should allow these two cases would be
> sufficient.  Note that I am suggesting setting these to False, which
> will break compatibility, but I believe that this is really what the
> average user is expecting anyways.

How could it break compatibility? From my testing (i.e., running your
test cases), passing in NaN or Inf raises exceptions at the moment. At
this point, it's impossible for any patch dealing with Inf and NaN to
break backwards compatibility, because there is no working baseline
behavior.

> If I can get a confirmation that this behavior will be acceptable then
> I will go ahead and submit an updated patch that reflects this
> change.  This time I will ping again in one week :)

Adding a configuration doesn't always solve a problem. More often than
not, it adds a new problem. This is one of those cases.

Putting a choice in the hands of a user which can come back and bite
them is not in the style of Django. Defining a DecimalField with
allow_inf=True will cause errors if you use a Postgres database. I'm
not about to commit code that will allow you to have a valid Django
configuration that throws errors in production.

This is why a survey of the current level of support in databases is
important. If, for example, no database supports Inf, then there is no
reason to even have an allow_inf setting. If support is varied, then
we need to have a discussion about the right way to handle the
variation.

There is also the issue of good API design to consider. From a
practical standpoint, I'm having difficulty thinking of a reason why
allow_nan needs to exist - why should an end user be allowed to submit
as a form value that is, a priori, known to be invalid? Essentially,
you're allowing the user to submit "divide by zero" as a valid form
value - what is the use case for this?

In summary, the process goes like this:
 1. Get the API right
 2. Implement it.

We're still on step 1. :-)

> Enjoy the thanksgiving,

Thanks, but FYI: Thanksgiving on the last Thursday in November is a
US-only holiday. It's held on other dates in some countries, and not
at all in others. Australia doesn't celebrate Thanksgiving at all.

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




Re: Feedback on ticket 7777

2009-11-25 Thread thebitguru
Thanks for the reply, Russ.

I need to revise the patch, but I need some confirmation.  I am not
sure if it is worth determining what all the different databases
support.  I think optional parameters (allow_{inf,nan}=False) that let
the user specify that django should allow these two cases would be
sufficient.  Note that I am suggesting setting these to False, which
will break compatibility, but I believe that this is really what the
average user is expecting anyways.

If I can get a confirmation that this behavior will be acceptable then
I will go ahead and submit an updated patch that reflects this
change.  This time I will ping again in one week :)

Enjoy the thanksgiving,
Farhan

On Nov 25, 5:56 pm, Russell Keith-Magee 
wrote:
> On Thu, Nov 26, 2009 at 2:15 AM, thebitguru  wrote:
> > Anyone?
>
> > On Nov 23, 6:38 pm, thebitguru  wrote:
> >> Hi,
>
> >> Can I please get some feedback on this ticket?  I am hoping that we
> >> can get this in soon.
>
> >>http://code.djangoproject.com/ticket/
>
> Echoing Alex's comment - responding to this was on my todo list, but
> I've been fighting a head cold for the last few days. On top of that -
> we're in the feature development phase, so non-critical bug fixes
> aren't taking the highest priority at the moment.
>
> That said: the patch itself looks like a fine implementation of a
> given behaviour.
>
> What isn't clear is that the behavior implemented is correct. Malcolm
> flagged this in his original comments - NaN and Inf are CPU and
> database-dependent values. Postgres can't support Inf, but can support
> NaN; I don't know what the situation is with other databases. Inf and
> NaN are both Decimal values - unconditionally raising a validation
> error doesn't seem like the right approach to me.
>
> So - the patch is fine, as long as we accept the design it implements.
> Now you need to convince us that the design is correct.
>
> 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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




Re: Feedback on ticket 7777

2009-11-25 Thread thebitguru
Sorry, I submitted that patch about a month ago and that was the date
stuck in my head :)  I just realized that I made my original post only
two days ago.  I apologize.

On Nov 25, 12:29 pm, Alex Gaynor  wrote:
> On Wed, Nov 25, 2009 at 12:15 PM, thebitguru  wrote:
> > Anyone?
>
> > On Nov 23, 6:38 pm, thebitguru  wrote:
> >> Hi,
>
> >> Can I please get some feedback on this ticket?  I am hoping that we
> >> can get this in soon.
>
> >>http://code.djangoproject.com/ticket/
>
> >> Thanks,
> >> Farhan
>
> > --
>
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> Please be patient.  At least in the US it's thanksgiving time so I
> imagine most of the American committers are busy, plus this list has
> been pretty low traffic the last few days, no one is ignoring your
> message, people are just busy.
>
> 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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




Re: What's the expected behavior of (cached) instances of deleted objects?

2009-11-25 Thread Russell Keith-Magee
On Thu, Nov 26, 2009 at 12:04 AM, Johannes Dollinger
 wrote:
> QuerySet.delete() currently sets the primary key and all nullable
> foreign keys (to deleted objects) of instances passed to signal
> handlers to None. No cache is updated.
>
> Model.delete() will do the same, but as these instances are collected
> by traversing related object descriptors all reverse o2o field caches
> will be updated.

Are you sure there is a discrepancy here?

ModelBase.delete() creates a CollectedObjects() structure, then
invokes self._collect_sub_objects() to populate it. It then invokes
delete_objects() to delete the objects.

QuerySet.delete() creates a CollectedObjects() structure, then invokes
obj._collect_sub_objects() on each of the objects in the queryset to
populate. It then invokes delete_objects() to delete the objects.

As far as I can make out, both populate the object caches the same way.

> Is this an accidental side effect or desired behavior?

If you are deleting a single object X, X.delete() deletes the object,
so the values in the cache are irrelevant. Similarly, if you delete a
queryset Y, all the items in Y will be deleted, and all the values in
the cache will be irrelevant.

In the case of an object Z that points at X (or an object in Y), but
doesn't result in a cacscading delete, the cache in Z should be
cleared. This is already done for nullable keys; I imagine your code
will need to implement something similar to handle non-cascading
cases.

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




Re: Why not datetime.utcnow() in auto_now/auto_now_add

2009-11-25 Thread Russell Keith-Magee
On Wed, Nov 25, 2009 at 7:10 PM, jedie  wrote:
> On 25 Nov., 00:36, Russell Keith-Magee  wrote:
>> Why would it be? A datetime field isn't necessarily stored in UTC. It
>> uses datetime.now() because that will return the same time as
>> settings.TIME_ZONE.
>
> To improve my understanding: What if the server changed and the time
> zone is not the same? IMHO the user can choose: 1. leave the
> settings.TIME_ZONE to the old value, so all old datetimes are right,
> but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE
> and old datetimes would be wrong, but new are right. Isn't it?

If the server changes, then it's up to the admin to manage that
change. Django *won't* make a change that will silently destroy the
integrity of existing databases in the field just by updating code,
which is *exactly* what changing to utcnow would do. Right now, there
are *thousands* of Django installations in the field - including many
of my own - that rely on the fact that auto_now uses datetime.now()
and returns a time localized to TIME_ZONE.

This behavior may be flawed, but it doesn't change the fact that this
is the way it currently is.

Storing datetimes in UTC may be a better default strategy, but that
doesn't change the way it currently is.

I am in complete agreement that Django should have better support for
time zones. As Rob Hudson pointed out, there is a long-standing ticket
requesting this (#2626). Changing the behavior of auto_now to return
utcnow doesn't address the larger problem.

>> On top of that, making this change would be a *huge* backwards
>> incompatibility, as any existing uses of auto_now etc would break.
>
> Yes. But it's easy to add a settings and the admin can choose between
> now or utcnow. The default settings should be set utcnow.

No, on two counts.

 1. Adding a setting to fix a problem doesn't fix a problem. It adds a
new problem.
 2. The existing value is datetime.now. *If* we were to add such a
setting (and let me tell you right now - we aren't going to), the
default value *must* be to use datetime.now - otherwise you don't get
backwards compatibility by default.

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




Re: Feedback on ticket 7777

2009-11-25 Thread Russell Keith-Magee
On Thu, Nov 26, 2009 at 2:15 AM, thebitguru  wrote:
> Anyone?
>
> On Nov 23, 6:38 pm, thebitguru  wrote:
>> Hi,
>>
>> Can I please get some feedback on this ticket?  I am hoping that we
>> can get this in soon.
>>
>> http://code.djangoproject.com/ticket/

Echoing Alex's comment - responding to this was on my todo list, but
I've been fighting a head cold for the last few days. On top of that -
we're in the feature development phase, so non-critical bug fixes
aren't taking the highest priority at the moment.

That said: the patch itself looks like a fine implementation of a
given behaviour.

What isn't clear is that the behavior implemented is correct. Malcolm
flagged this in his original comments - NaN and Inf are CPU and
database-dependent values. Postgres can't support Inf, but can support
NaN; I don't know what the situation is with other databases. Inf and
NaN are both Decimal values - unconditionally raising a validation
error doesn't seem like the right approach to me.

So - the patch is fine, as long as we accept the design it implements.
Now you need to convince us that the design is correct.

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




Re: Django needs for normal sequence of handlers for request processing

2009-11-25 Thread Sean Brant
Oh, forgot there are also signals that might help.
http://docs.djangoproject.com/en/dev/ref/signals/#module-django.core.signals

:)

--

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




Re: Django needs for normal sequence of handlers for request processing

2009-11-25 Thread Sean Brant
Not sure if this would solve the problem, but have a look at
django.utils.ddecorators.decorator_from_middleware.

"""
Given a middleware class (not an instance), returns a view decorator. This
lets you use middleware functionality on a per-view basis.
"""

This also might be best discussed on django-users for now.

--

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




Re: Django needs for normal sequence of handlers for request processing

2009-11-25 Thread Robert Coup
Hi Serg,

(replying to the list)

On Thu, Nov 26, 2009 at 4:09 AM, serg  wrote:
>
> hmm.. yes. it's almost the same i mean.
> but, all middlewares calls for each request... It's bad (imho).
> also in 99.99% cases it wil be work nice...
> thanks!
>
> This method {'filter_ip':True} is unsafe.
>
> Look:
> First developer defined MembersAreaAuthMiddleware
> and create:
> (r'^members/', include('members.urls'), {'auth':True}),
> and second developer defined SmtpMiddleware
> (r'^private/', include('public.private.urls'), {'auth':True}),
> Conflict.
>
> If use params as names of handlers... And call them into one
> middleware... Hmm.. It will be normal handlers :)
>

Sure, I didn't say it was perfect! Just one possible solution. I doubt
the overhead of one extra function call for the middleware is going to
make that big a difference...

Rob :)

--

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




Re: Why not datetime.utcnow() in auto_now/auto_now_add

2009-11-25 Thread Rob Hudson
On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee
 wrote:
>
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
>

I like the solution proposed on ticket 10587:
http://code.djangoproject.com/ticket/10587

Basically, it proposes that timezones are handled analogous to how
Unicode is handled -- that is, everything within Django boundaries is
treated as UTC, with timezone conversions happening on input and
output, but never within Django and always stored as UTC in the
database.

Ticket 10587 was closed as a duplicate of 2626, but I think 10587 has
the better description and proposal in it.

-Rob

--

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




Re: Feedback on ticket 7777

2009-11-25 Thread Alex Gaynor
On Wed, Nov 25, 2009 at 12:15 PM, thebitguru  wrote:
> Anyone?
>
> On Nov 23, 6:38 pm, thebitguru  wrote:
>> Hi,
>>
>> Can I please get some feedback on this ticket?  I am hoping that we
>> can get this in soon.
>>
>> http://code.djangoproject.com/ticket/
>>
>> Thanks,
>> Farhan
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

Please be patient.  At least in the US it's thanksgiving time so I
imagine most of the American committers are busy, plus this list has
been pretty low traffic the last few days, no one is ignoring your
message, people are just busy.

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




Re: Feedback on ticket 7777

2009-11-25 Thread thebitguru
Anyone?

On Nov 23, 6:38 pm, thebitguru  wrote:
> Hi,
>
> Can I please get some feedback on this ticket?  I am hoping that we
> can get this in soon.
>
> http://code.djangoproject.com/ticket/
>
> Thanks,
> Farhan

--

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




What's the expected behavior of (cached) instances of deleted objects?

2009-11-25 Thread Johannes Dollinger
QuerySet.delete() currently sets the primary key and all nullable  
foreign keys (to deleted objects) of instances passed to signal  
handlers to None. No cache is updated.

Model.delete() will do the same, but as these instances are collected  
by traversing related object descriptors all reverse o2o field caches  
will be updated.

Is this an accidental side effect or desired behavior?

I'm asking because my patch for #7539 currently does not update o2o  
caches. But that could be fixed - if really necessary.

Relevant thread: 
http://groups.google.com/group/django-developers/browse_thread/thread/6e88b6315f489403/

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




Re: Django needs for normal sequence of handlers for request processing

2009-11-25 Thread Robert Coup
On Wed, Nov 25, 2009 at 11:08 PM, serg  wrote:
>
> For example:

you can already do something like this (middleware conditional on
urls) via the view middleware mechanism.

in urls:
...
(r'^members/private/', include('members.private.urls'), {'filter_ip':True}),
...

then the middleware:

class FilterIPMiddleware(object):
  def process_view(self, request, view_func, view_args, view_kwargs):
    if view_kwargs.get('filter_ip'):
      del view_kwargs['filter_ip']
      ... check ip...
      if ip_is_bad:
        return HttpResponseForbidden("Naughty! Bad!")

http://www.djangosnippets.org/snippets/85/ describes using the same
idea to enforce certain URLs being accessed only via SSL (and
redirecting to HTTPS if they're accessed via HTTP)

HTH,

Rob :)

--

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




Django needs for normal sequence of handlers for request processing

2009-11-25 Thread serg

The request processing can be easy if developers of sites can define
prehandlers and posthandlers for each urls.py (or views.py?).

prehandler: the connection middleware. It calls before request
object was created. Only connection detailes needed for prehandler
processing (no session, no user, no any request-specified objects).
Prehandlers are used for connection detailed checking.
posthandler: the process middleware. It's usually middleware, but
it can be defined for specific urls.py and was processed only for this
urls.py and no other.

When the server started, it create map of handlers for urls and calls
prehandlers and posthandlers according the map. The view (defined in
view.py) is used only if no handlers returned response object. -- i.e.
the request processing sequence interrupted and server returns the
response if the handler returned response object.

For example:

The site have a members area '^memers/.*$'. The members area have a
private zone '^members/private/.*$' (additional authentication demands
for access into). Other urls is a public, but some external ip was
banned.

In urls.py I create prehandler to reject banned ip.
In members.urls I create posthandler for user authentication.
In members.private.urls I create posthandler for additional
authentication.

-- A:
1. The server get http request: "GET /members/list.xml" (user is
authenticated)
2. django try process prehandlers:
prehandler
members.prehandlers  # not exists
3. django create request object
4. django try process posthandlers:
posthandler  # it is a settings.middlewares now. (it was a bad
idea to put middlewares call map into global settings)
members.posthandler  (checking for user authentication)
5. process the view:
(r'^list.xml$', called members.views.list),

-- B:
1. The server get http request: "GET /members/private/
detailes.xml" (user is authenticated and has permissions for access
into private area):
2. django try process prehandlers:
prehandler
members.prehandlers  # not exists
members.private.prehandler  #not exists
3. django create request object
4. django try process posthandlers:
posthandler
members.posthandler  (checking for user authentication)
members.private.posthandler  (checking for additional
authentication)
5. process the view:
(r'^detailes.xml$', called members.private.views.detailes),

-- C:
1. The server get http request: "GET /members/list.xml" from banned
ip:
2. django try process prehandlers:
prehandler  # ip banned, prehandler returns response and
server sending response

-- D:
1. The server get http request: "GET /members/list.xml" and user is
not authenticated:
2. django try process prehandlers:
prehandler
members.prehandlers  # not exists
3. django create request object
4. django try process posthandlers:
posthandler
members.posthandler  # user is not authenticated, The
members.posthandler returns HttpResponseRedirect('/login.xml') and the
server send response to user

When I created members.posthandler I forgot authentication about. All
urls '^members/.*$' was automatically verified for user authentication
and all urls '^members/private/.*$' was automatically checked for
additional authorization since I defined members.private.posthandler.
No decorators. Just define any views into members/views.py or into
members/private/views.py and enjoy by result now.

P.S. I used this sceme in perl + mason constructions and it was nice.
P. P.S. Sorr for my english. :) I can read but can't speack or write.

--

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




Re: Why not datetime.utcnow() in auto_now/auto_now_add

2009-11-25 Thread jedie
On 25 Nov., 00:36, Russell Keith-Magee  wrote:
> Why would it be? A datetime field isn't necessarily stored in UTC. It
> uses datetime.now() because that will return the same time as
> settings.TIME_ZONE.

To improve my understanding: What if the server changed and the time
zone is not the same? IMHO the user can choose: 1. leave the
settings.TIME_ZONE to the old value, so all old datetimes are right,
but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE
and old datetimes would be wrong, but new are right. Isn't it?

> On top of that, making this change would be a *huge* backwards
> incompatibility, as any existing uses of auto_now etc would break.

Yes. But it's easy to add a settings and the admin can choose between
now or utcnow. The default settings should be set utcnow.

Mfg.

Jens Diemer

--

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