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

Re: Oracle/GIS Testers Needed

[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

[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

[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

[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: Oracle/GIS Testers Needed

[redetin]

On Sat, Nov 21, 2009 at 1:36 AM, Alex Gaynor  wrote:

> On Fri, Nov 20, 2009 at 3:56 PM, Karen Tracey  wrote:
> >> Just running the Oracle tests is enough for now.  I've fixed the error
> >> you spotted with the stray import left over and pushed that to github.
> >
> > I get 6 failures and 26 errors but I do not know if any of them have
> > anything to do with multidb.  The output is here:
> >
> > http://pastebin.com/m2c763672
> >
> > By contrast on trunk I get 7 failures and 26 errors:
> >
> > http://pastebin.com/mf7c57a6
> >
> > The unable to create INITIAL extent errors are new -- I've not seen them
> > before, but I am getting some on trunk as well as multidb (though more on
> > multidb).  I get the impression it may mean my install has some limits on
> > how big things can grow, and tests are now exceeding those limits.  Not
> > sure, and I don't have time to spend on trying to figure it out right
> now.
> >
> > Nor do I have time to see which failure goes away with multidb, sorry --
> so
> > I figured I'd just post out the results and you can take a look if you
> think
> > it would be useful.
> >
> > 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-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=.
> >
>
> Thanks!
>
> Unfortunately i have basically no idea what any of those Oracle bugs
> mean.  However, the few non-frightening errors I saw all also appeared
> on trunk, so I guess my refactor basically didn't break anything.
>
> 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
>
>
Initial extent errors happens because datafile allocated for  temporary
tablespace is full. It's hardcoded in
django/db/backends/oracle/creation.py:L159,L163 (in trunk) to be 100M(bytes)
which apparently is not enough anymore. Too bad that it's so late that I
don't have time to test how much space tests actually needs now but it's
definitely more than 100M.

-- 

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

[Alex Gaynor]

On Fri, Nov 20, 2009 at 10:52 PM, Justin Bronn  wrote:
>
>> For GIS I'm fairly certain that's broken, however I'm not quite setup
>> for running the GIS tests yet, therefore if you're set up for it and
>> can run the tests please just reply with your tracebacks here
>> (preferably with them on a pastebin like paste.pocoo.org though :))
>> and I'll try to sort it out.
>
> Yes, multi-db is seriously broken with GIS on all backends (it'd be
> pointless to list all the errors here).  Basically, the massive shift
> of `Query` internals to `SQLCompiler` is the root of the problem --
> there needs to be a corresponding `GeoSQLCompiler` with `GeoQuerySet`
> and `GeoQuery` wired to use it accordingly.  I'll try to look at it in
> more detail this weekend and see if I can sketch out a better idea of
> what needs to be done, but so far it's looking "non-trivial."
>
> -Justin
>
> --
>
> 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=.
>
>
>

Thanks for taking a look Justin.  I won't have time to look into it
myself this weekend, but if you have any questions feel free to ask
here on IRC and I can try to help.  Otherwise I will have time this
coming week and can hopefully start digging into this, as it's
probably the single most important tihng to fix up.

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

Re: Oracle/GIS Testers Needed

[Justin Bronn]

> For GIS I'm fairly certain that's broken, however I'm not quite setup
> for running the GIS tests yet, therefore if you're set up for it and
> can run the tests please just reply with your tracebacks here
> (preferably with them on a pastebin like paste.pocoo.org though :))
> and I'll try to sort it out.

Yes, multi-db is seriously broken with GIS on all backends (it'd be
pointless to list all the errors here).  Basically, the massive shift
of `Query` internals to `SQLCompiler` is the root of the problem --
there needs to be a corresponding `GeoSQLCompiler` with `GeoQuerySet`
and `GeoQuery` wired to use it accordingly.  I'll try to look at it in
more detail this weekend and see if I can sketch out a better idea of
what needs to be done, but so far it's looking "non-trivial."

-Justin

--

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

Re: Oracle/GIS Testers Needed

[Alex Gaynor]

On Fri, Nov 20, 2009 at 3:56 PM, Karen Tracey  wrote:
>> Just running the Oracle tests is enough for now.  I've fixed the error
>> you spotted with the stray import left over and pushed that to github.
>
> I get 6 failures and 26 errors but I do not know if any of them have
> anything to do with multidb.  The output is here:
>
> http://pastebin.com/m2c763672
>
> By contrast on trunk I get 7 failures and 26 errors:
>
> http://pastebin.com/mf7c57a6
>
> The unable to create INITIAL extent errors are new -- I've not seen them
> before, but I am getting some on trunk as well as multidb (though more on
> multidb).  I get the impression it may mean my install has some limits on
> how big things can grow, and tests are now exceeding those limits.  Not
> sure, and I don't have time to spend on trying to figure it out right now.
>
> Nor do I have time to see which failure goes away with multidb, sorry -- so
> I figured I'd just post out the results and you can take a look if you think
> it would be useful.
>
> 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-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=.
>

Thanks!

Unfortunately i have basically no idea what any of those Oracle bugs
mean.  However, the few non-frightening errors I saw all also appeared
on trunk, so I guess my refactor basically didn't break anything.

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

Re: Oracle/GIS Testers Needed

[Karen Tracey]

>
> Just running the Oracle tests is enough for now.  I've fixed the error
> you spotted with the stray import left over and pushed that to github.
>

I get 6 failures and 26 errors but I do not know if any of them have
anything to do with multidb.  The output is here:

http://pastebin.com/m2c763672

By contrast on trunk I get 7 failures and 26 errors:

http://pastebin.com/mf7c57a6

The unable to create INITIAL extent errors are new -- I've not seen them
before, but I am getting some on trunk as well as multidb (though more on
multidb).  I get the impression it may mean my install has some limits on
how big things can grow, and tests are now exceeding those limits.  Not
sure, and I don't have time to spend on trying to figure it out right now.

Nor do I have time to see which failure goes away with multidb, sorry -- so
I figured I'd just post out the results and you can take a look if you think
it would be useful.

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

Re: Oracle/GIS Testers Needed

[Alex Gaynor]

On Fri, Nov 20, 2009 at 11:03 AM, ben  wrote:
> Hi Alex,
>
> I have oracle at work with all versions from 9i to 11. I'd be happy to
> run the tests on all of those verisons. I wonder if I could ask a
> small favour in return though:
>
> In our organisation we have a lot of legacy date/time data modeled as
> the year 0001-01-01 and then the time in situations where the time is
> all we're interested in. This is currently causing a headache due to
> http://code.djangoproject.com/ticket/10866 which has a patch and is
> ready for checkin. The patch is basically a one character change to
> datetime_safe.py which zero pads dates with year < 1000. Would you
> mind fixing it?
>
> Cheers,
> Ben
>
> On Nov 20, 3:17 pm, Alex Gaynor  wrote:
>> On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey  wrote:
>> > On Fri, Nov 20, 2009 at 1:14 AM, 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.
>>
>> > The queries test ran OK once I removed:
>>
>> > from django.db.backends.oracle import query
>>
>> > from django/db/backends/oracle/base.py
>>
>> > I guessed based on the fact that django/db/backends/oracle/query.py was
>> > removed in the last commit that the import was leftover from a
>> > restructuring. I am not sure but it looks like there may also be some other
>> > dead stuff referencing this query module (the query_class method in
>> > DatabaseOperations?), but I did not touch that, just removed that one
>> > import.
>>
>> > I've got the full suite running now, but that will take a while.
>>
>> > So far I am testing with just Oracle backend specified.  The last time I
>> > tested this branch I also had a test config that specified multiple dbs -- 
>> > a
>> > default and an extra one.  Not sure if you wanted to test that at this 
>> > point
>> > so I started with the simpler one.
>>
>> > 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-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=.
>>
>> Just running the Oracle tests is enough for now.  I've fixed the error
>> you spotted with the stray import left over and pushed that to github.
>>
>> Thanks,
>> 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=.
>
>
>

I'm not familiar with that ticket, nor the issues surrounding it, so
I'd be uncomfortable applying a patch in any event, further that
ticket isn't specific to my branch so it should go through the normal
process of being committed to trunk, then I'll happily merge it in.

Thanks for offering to run the tests!

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

Re: Oracle/GIS Testers Needed

[ben]

Hi Alex,

I have oracle at work with all versions from 9i to 11. I'd be happy to
run the tests on all of those verisons. I wonder if I could ask a
small favour in return though:

In our organisation we have a lot of legacy date/time data modeled as
the year 0001-01-01 and then the time in situations where the time is
all we're interested in. This is currently causing a headache due to
http://code.djangoproject.com/ticket/10866 which has a patch and is
ready for checkin. The patch is basically a one character change to
datetime_safe.py which zero pads dates with year < 1000. Would you
mind fixing it?

Cheers,
Ben

On Nov 20, 3:17 pm, Alex Gaynor  wrote:
> On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey  wrote:
> > On Fri, Nov 20, 2009 at 1:14 AM, 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.
>
> > The queries test ran OK once I removed:
>
> > from django.db.backends.oracle import query
>
> > from django/db/backends/oracle/base.py
>
> > I guessed based on the fact that django/db/backends/oracle/query.py was
> > removed in the last commit that the import was leftover from a
> > restructuring. I am not sure but it looks like there may also be some other
> > dead stuff referencing this query module (the query_class method in
> > DatabaseOperations?), but I did not touch that, just removed that one
> > import.
>
> > I've got the full suite running now, but that will take a while.
>
> > So far I am testing with just Oracle backend specified.  The last time I
> > tested this branch I also had a test config that specified multiple dbs -- a
> > default and an extra one.  Not sure if you wanted to test that at this point
> > so I started with the simpler one.
>
> > 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-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=.
>
> Just running the Oracle tests is enough for now.  I've fixed the error
> you spotted with the stray import left over and pushed that to github.
>
> Thanks,
> 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=.

Re: Oracle/GIS Testers Needed

[Alex Gaynor]

On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey  wrote:
> On Fri, Nov 20, 2009 at 1:14 AM, 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.
>>
>
> The queries test ran OK once I removed:
>
> from django.db.backends.oracle import query
>
> from django/db/backends/oracle/base.py
>
> I guessed based on the fact that django/db/backends/oracle/query.py was
> removed in the last commit that the import was leftover from a
> restructuring. I am not sure but it looks like there may also be some other
> dead stuff referencing this query module (the query_class method in
> DatabaseOperations?), but I did not touch that, just removed that one
> import.
>
> I've got the full suite running now, but that will take a while.
>
> So far I am testing with just Oracle backend specified.  The last time I
> tested this branch I also had a test config that specified multiple dbs -- a
> default and an extra one.  Not sure if you wanted to test that at this point
> so I started with the simpler one.
>
> 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-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=.
>

Just running the Oracle tests is enough for now.  I've fixed the error
you spotted with the stray import left over and pushed that to github.

Thanks,
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=.

Re: Oracle/GIS Testers Needed

[Karen Tracey]

On Fri, Nov 20, 2009 at 1:14 AM, 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.
>
>
The queries test ran OK once I removed:

from django.db.backends.oracle import query

from django/db/backends/oracle/base.py

I guessed based on the fact that django/db/backends/oracle/query.py was
removed in the last commit that the import was leftover from a
restructuring. I am not sure but it looks like there may also be some other
dead stuff referencing this query module (the query_class method in
DatabaseOperations?), but I did not touch that, just removed that one
import.

I've got the full suite running now, but that will take a while.

So far I am testing with just Oracle backend specified.  The last time I
tested this branch I also had a test config that specified multiple dbs -- a
default and an extra one.  Not sure if you wanted to test that at this point
so I started with the simpler one.

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

Re: Oracle/GIS Testers Needed

[Russell Keith-Magee]

On Fri, Nov 20, 2009 at 3:19 PM, 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.
>>
>> For GIS I'm fairly certain that's broken, however I'm not quite setup
>> for running the GIS tests yet, therefore if you're set up for it and
>> can run the tests please just reply with your tracebacks here
>> (preferably with them on a pastebin like paste.pocoo.org though :))
>> and I'll try to sort it out.
>>
>> Thanks all,
>> Alex
>>
>
> We can try to run and experiment all that since we need multidb support
> and we run Oracle with heavy GIS stuff.

Thanks for the offer. For the moment, only the Oracle stuff requires
testing - GIS will need testing soon. We'll be sure to tap you on the
shoulder again when the GIS stuff is ready :-)

> Is there any special requirements that I need to take account before
> running tests?

For the moment, the priority isn't testing anything specifically
multi-database. We've made a lot of fairly big changes to the
internals of queries, and we just need to check that the N=1 case
still works across the board.

So - all you need to do is follow the normal Django testing requirements [1].

[1] 
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

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

Re: Oracle/GIS Testers Needed

[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.
> 
> For GIS I'm fairly certain that's broken, however I'm not quite setup
> for running the GIS tests yet, therefore if you're set up for it and
> can run the tests please just reply with your tracebacks here
> (preferably with them on a pastebin like paste.pocoo.org though :))
> and I'll try to sort it out.
> 
> Thanks all,
> Alex
> 

We can try to run and experiment all that since we need multidb support
and we run Oracle with heavy GIS stuff. 

Is there any special requirements that I need to take account before
running tests?

-- 

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

Oracle/GIS Testers Needed

[Alex Gaynor]

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.

For GIS I'm fairly certain that's broken, however I'm not quite setup
for running the GIS tests yet, therefore if you're set up for it and
can run the tests please just reply with your tracebacks here
(preferably with them on a pastebin like paste.pocoo.org though :))
and I'll try to sort it out.

Thanks all,
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=.