Re: Problem with history view in admin page

[Yuri Baburov]

Hi Russell,

On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee
 wrote:
> 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.
First, since we have a lot of fields already like
PositiveIntegerField, there is no problem to add one more specific
field. It's not new kind of fields distinction, it's just one more
specie of them.

But then much more general problem arises: use of CLOB instead of
varchar2 where 255> 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.
Yes, they are always a pain, but in such situation I'm feeling like in
a surgeon.
I tend to prefer to do surgery once instead of living with constant pain.
For this problem, pain is not strong, but surgery is quick, and those who use
newer Django won't even know about that pain.
If we'll settle on a good enough solution, of course.

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

--

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

[Russell Keith-Magee]

On Thu, Nov 26, 2009 at 11:44 PM, Ian Kelly  wrote:
> On Thu, Nov 26, 2009 at 8:38 AM, Russell Keith-Magee
>  wrote:
>> Yes - this does help. The confirms my suspicion - the problem is that
>> the fixture loaded in FixtureTestCase.test_fixture_loading isn't being
>> cleared before running the tests in QueryTestCase.
>>
>> The annoying thing is that I don't see this problem on any other
>> database, so there is something specific about transaction rollback on
>> Oracle. I can't see anything in that code that is should be
>> Oracle-specific behavior.
>>
>> The magic code is in _fixture_teardown(), starting at line 487 of
>> django/tests/testcases.py. That method *should* be resetting the
>> database at the end of multiple_database.FixtureTestCase, but
>> evidently it isn't. Either the transaction rollback code isn't getting
>> invoked, or it is getting invoked but not behaving as expected.
>>
>> Any debugging assistance you can provide here would be most welcome.
>>
>> Yours
>> Russ Magee %-)
>
> It sounds like you're running into another case of #11101.  The basic
> problem is that loading fixtures involves resetting sequences, which
> requires running DDL, which causes an implicit commit.

Looks like that explains it. Thanks for stepping in and saving my
sanity, Ian :-)

I've added a note to #11101 so that this bit of knowledge isn't forgotten.

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

[Jani Tiainen]

On Thu, Nov 26, 2009 at 5:44 PM, Ian Kelly  wrote:

> On Thu, Nov 26, 2009 at 8:38 AM, Russell Keith-Magee
>  wrote:
> > Yes - this does help. The confirms my suspicion - the problem is that
> > the fixture loaded in FixtureTestCase.test_fixture_loading isn't being
> > cleared before running the tests in QueryTestCase.
> >
> > The annoying thing is that I don't see this problem on any other
> > database, so there is something specific about transaction rollback on
> > Oracle. I can't see anything in that code that is should be
> > Oracle-specific behavior.
> >
> > The magic code is in _fixture_teardown(), starting at line 487 of
> > django/tests/testcases.py. That method *should* be resetting the
> > database at the end of multiple_database.FixtureTestCase, but
> > evidently it isn't. Either the transaction rollback code isn't getting
> > invoked, or it is getting invoked but not behaving as expected.
> >
> > Any debugging assistance you can provide here would be most welcome.
> >
> > Yours
> > Russ Magee %-)
>
> It sounds like you're running into another case of #11101.  The basic
> problem is that loading fixtures involves resetting sequences, which
> requires running DDL, which causes an implicit commit.
>
>
>
>
>
That must be it. Any DDL operation in Oracle does implicit commit before
actually execting DDL. Very hard to get around since it's how DDL works in
Oracle.

--

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

[Ian Kelly]

On Thu, Nov 26, 2009 at 8:38 AM, Russell Keith-Magee
 wrote:
> Yes - this does help. The confirms my suspicion - the problem is that
> the fixture loaded in FixtureTestCase.test_fixture_loading isn't being
> cleared before running the tests in QueryTestCase.
>
> The annoying thing is that I don't see this problem on any other
> database, so there is something specific about transaction rollback on
> Oracle. I can't see anything in that code that is should be
> Oracle-specific behavior.
>
> The magic code is in _fixture_teardown(), starting at line 487 of
> django/tests/testcases.py. That method *should* be resetting the
> database at the end of multiple_database.FixtureTestCase, but
> evidently it isn't. Either the transaction rollback code isn't getting
> invoked, or it is getting invoked but not behaving as expected.
>
> Any debugging assistance you can provide here would be most welcome.
>
> Yours
> Russ Magee %-)

It sounds like you're running into another case of #11101.  The basic
problem is that loading fixtures involves resetting sequences, which
requires running DDL, which causes an implicit commit.

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

[Russell Keith-Magee]

On Thu, Nov 26, 2009 at 10:56 PM, Jani Tiainen  wrote:
> On Thu, 2009-11-26 at 21:56 +0800, Russell Keith-Magee wrote:
>> On Thu, Nov 26, 2009 at 9:37 PM, Jani Tiainen  wrote:
>> > On Thu, 2009-11-26 at 20:23 +0800, Russell Keith-Magee wrote:
>> >
>> >> * Do you still get the same failures if you convert QueryTestCase into
>> >> a TransactionTestCase (i.e., change the import "from django.test
>> >> import TestCase" to "from django.test import TransactionTestCase as
>> >> TestCase")
>> >
>> > All three passed in isolated tests.
>>
>> Do the TransactionTestCase versions still pass when you execute the
>> full multi-db suite? If so, I think we have narrowed the problem down
>> to the rollback code.
>
> Yes they pass.
>
> I thought I wrote it down but I might have forgotten that one.
>
>> A few more debug data points:
>>
>>  * Could you please run the full multi-db suite with verbosity=2; it
>> would be helpful to see the exact order in which the tests are being
>> executed
>
> testrun1.log
>
>>  * Could you run just the multiple_database.QueryTestCase test case
>> (again, with verbosity=2, so I can see the test order). I'm wondering
>> if the problem might be a leakage of fixture loading.
>>
>
> testrun2.log
>
>
> Made those as attachments since theyu're so huge ones... HTH.

Yes - this does help. The confirms my suspicion - the problem is that
the fixture loaded in FixtureTestCase.test_fixture_loading isn't being
cleared before running the tests in QueryTestCase.

The annoying thing is that I don't see this problem on any other
database, so there is something specific about transaction rollback on
Oracle. I can't see anything in that code that is should be
Oracle-specific behavior.

The magic code is in _fixture_teardown(), starting at line 487 of
django/tests/testcases.py. That method *should* be resetting the
database at the end of multiple_database.FixtureTestCase, but
evidently it isn't. Either the transaction rollback code isn't getting
invoked, or it is getting invoked but not behaving as expected.

Any debugging assistance you can provide here would be most 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-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

[Russell Keith-Magee]

On Thu, Nov 26, 2009 at 9:37 PM, Jani Tiainen  wrote:
> On Thu, 2009-11-26 at 20:23 +0800, Russell Keith-Magee wrote:
>
>> * Do you still get the same failures if you convert QueryTestCase into
>> a TransactionTestCase (i.e., change the import "from django.test
>> import TestCase" to "from django.test import TransactionTestCase as
>> TestCase")
>
> All three passed in isolated tests.

Do the TransactionTestCase versions still pass when you execute the
full multi-db suite? If so, I think we have narrowed the problem down
to the rollback code.

A few more debug data points:

 * Could you please run the full multi-db suite with verbosity=2; it
would be helpful to see the exact order in which the tests are being
executed

 * Could you run just the multiple_database.QueryTestCase test case
(again, with verbosity=2, so I can see the test order). I'm wondering
if the problem might be a leakage of fixture loading.

Thanks,
Russ %-)

--

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

[Jani Tiainen]

On Thu, 2009-11-26 at 20:23 +0800, Russell Keith-Magee wrote:
> On Thu, Nov 26, 2009 at 5:03 PM, Jani Tiainen  wrote:
> > On Thu, 2009-11-26 at 01:44 -0600, Alex Gaynor wrote:
> >> 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
> >>
> >
> > ==
> > ERROR: Objects created on the default database don't leak onto other
> > databases
> > --
> > Traceback (most recent call last):
> >  File
> > "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
> >  line 34, in test_default_creation
> >Book.objects.get(title="Pro Django")
> >  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/manager.py",
> > line 119, in get
> >return self.get_query_set().get(*args, **kwargs)
> >  File "/home/KEYPRO/jtiai/src/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'}
> >
> > ==
> > FAIL: Queries are constrained to a single database
> > --
> > Traceback (most recent call last):
> >  File
> > "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
> >  line 117, in test_basic_queries
> >self.assertRaises(Book.DoesNotExist,
> > Book.objects.using('default').get, published__year=2009)
> > AssertionError: DoesNotExist not raised
> >
> > ==
> > FAIL: Objects created on another database don't leak onto the default
> > database
> > --
> > Traceback (most recent call last):
> >  File
> > "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
> >  line 76, in test_other_creation
> >title="Pro Django"
> > AssertionError: DoesNotExist not raised
> >
> > --
> > Ran 12 tests in 2.778s
> >
> > Well that's all for multiple_database tests configured so that "default"
> > points to my oracle and "other" points to sqlite3 memory database.
> 
> Thanks for that Jani.  These errors are extremely unusual - it appears
> as if the test cases aren't correctly flushing the database at the
> start of the test run.
> 
> For example - the ERROR on line 34 of the test case tests that a
> single instance of a book has been created on the default database,
> but two instances are found.However, there should only be 1 book in
> the database at that point.
> 
> I can't think of any reason this would be happening, though. To help
> track this down a bit:
> 
>  * Do you get the same failures if you run those tests in isolation? i.e.,
> 
> ./runtests --settings=oracle
> 

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

[Johannes Dollinger]

Am 26.11.2009 um 12:09 schrieb Russell Keith-Magee:

> On Thu, Nov 26, 2009 at 5:39 PM, Johannes Dollinger
>  wrote:
>>
>> Am 26.11.2009 um 03:47 schrieb 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.
>>
>> With QuerySet.delete() all instances traversed by
>> _collect_sub_objects() are only accessible from signal handlers,  
>> there
>> will be no surprises.
>> But with Model.delete() you can possible access the same instances
>> through reverse o2o descriptors.
>> Here is an example: http://dpaste.com/hold/125343/
>
> Looks to me like you've found some edge case errors. If I'm reading
> the test case right, the o2o field isn't nullable, so you should be
> getting None for c.pk, and DNE on every next/prev request.

There's currently no code that would update forward foreign key caches.
So it's the edge case that does the updates (reverse o2o) and the  
general case just leaves your object graph alone (including stale  
caches).

 class A(models.Model): pass
 class B(models.Model): a = models.ForeignKey(A)

 a = A.objects.create()
 b = B.objects.create(a=a)
 b.a.delete()

Although both instances have been deleted, `b.a` will still be  
accessible.
__
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: Oracle/GIS Testers Needed

[Russell Keith-Magee]

On Thu, Nov 26, 2009 at 5:03 PM, Jani Tiainen  wrote:
> On Thu, 2009-11-26 at 01:44 -0600, Alex Gaynor wrote:
>> 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
>>
>
> ==
> ERROR: Objects created on the default database don't leak onto other
> databases
> --
> Traceback (most recent call last):
>  File
> "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
>  line 34, in test_default_creation
>    Book.objects.get(title="Pro Django")
>  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/manager.py",
> line 119, in get
>    return self.get_query_set().get(*args, **kwargs)
>  File "/home/KEYPRO/jtiai/src/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'}
>
> ==
> FAIL: Queries are constrained to a single database
> --
> Traceback (most recent call last):
>  File
> "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
>  line 117, in test_basic_queries
>    self.assertRaises(Book.DoesNotExist,
> Book.objects.using('default').get, published__year=2009)
> AssertionError: DoesNotExist not raised
>
> ==
> FAIL: Objects created on another database don't leak onto the default
> database
> --
> Traceback (most recent call last):
>  File
> "/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
>  line 76, in test_other_creation
>    title="Pro Django"
> AssertionError: DoesNotExist not raised
>
> --
> Ran 12 tests in 2.778s
>
> Well that's all for multiple_database tests configured so that "default"
> points to my oracle and "other" points to sqlite3 memory database.

Thanks for that Jani.  These errors are extremely unusual - it appears
as if the test cases aren't correctly flushing the database at the
start of the test run.

For example - the ERROR on line 34 of the test case tests that a
single instance of a book has been created on the default database,
but two instances are found.However, there should only be 1 book in
the database at that point.

I can't think of any reason this would be happening, though. To help
track this down a bit:

 * Do you get the same failures if you run those tests in isolation? i.e.,

./runtests --settings=oracle
multiple_databases.QueryTestCase.test_default_creation

./runtests --settings=oracle
multiple_databases.QueryTestCase.test_other_creation

./runtests --settings=oracle multiple_databases.QueryTestCase.test_basic_queries

* Do you still get the same failures if you run with a file-backed
SQLite instance, rather 

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

[Russell Keith-Magee]

On Thu, Nov 26, 2009 at 5:39 PM, Johannes Dollinger
 wrote:
>
> Am 26.11.2009 um 03:47 schrieb 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.
>
> With QuerySet.delete() all instances traversed by
> _collect_sub_objects() are only accessible from signal handlers, there
> will be no surprises.
> But with Model.delete() you can possible access the same instances
> through reverse o2o descriptors.
> Here is an example: http://dpaste.com/hold/125343/

Looks to me like you've found some edge case errors. If I'm reading
the test case right, the o2o field isn't nullable, so you should be
getting None for c.pk, and DNE on every next/prev request.

>> 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.
>
> Unconditionally for all instances? That sounds like solution for #17
> is needed. Currently, nullable keys are only updated for instances
> that are collected in _collect_sub_objects().

No - not unconditionally. I'm only talking about instances where you
get access to an object through a descriptor, and subsequently the
object that provided that descriptor is deleted - essentially the case
you have described here

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

[serg]

megathanks to all

I will try to use something like:
(r'^members/', include('members.urls'), {'auth':True})
but {'auth':True} will consist of name of handler (handlers)

I'll try to create 1 middleware to process this filters. All handlers
will be called according by its names.

Yes, this is a crutch. But maybe it will be work...

--

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.

PEP 391 (Dictionary-Based Configuration for Logging) is now ready for review

[Vinay Sajip]

I've submitted PEP 391 for review on python-dev, and this may have a
bearing on adding logging support to Django. Some of the discussions
involved using a dictionary defined in settings.py to configure
logging.

Regards,

Vinay Sajip

--

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

Re: Oracle/GIS Testers Needed

[Jani Tiainen]

On Thu, 2009-11-26 at 01:44 -0600, Alex Gaynor wrote:
> 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
> 

==
ERROR: Objects created on the default database don't leak onto other
databases
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 34, in test_default_creation
Book.objects.get(title="Pro Django")
  File "/home/KEYPRO/jtiai/src/multidb/django/db/models/manager.py",
line 119, in get
return self.get_query_set().get(*args, **kwargs)
  File "/home/KEYPRO/jtiai/src/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'}

==
FAIL: Queries are constrained to a single database
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 117, in test_basic_queries
self.assertRaises(Book.DoesNotExist,
Book.objects.using('default').get, published__year=2009)
AssertionError: DoesNotExist not raised

==
FAIL: Objects created on another database don't leak onto the default
database
--
Traceback (most recent call last):
  File
"/home/KEYPRO/jtiai/src/multidb/tests/regressiontests/multiple_database/tests.py",
 line 76, in test_other_creation
title="Pro Django"
AssertionError: DoesNotExist not raised

--
Ran 12 tests in 2.778s

Well that's all for multiple_database tests configured so that "default"
points to my oracle and "other" points to sqlite3 memory database.


--

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.