thr3ads.net - Rails core - The Pagination Problem (and the can of worms it opened up) [Jan 2006]

If this information is useful, please help other people find it:
Share via:

Kevin Clark

2006-Jan-25 21:56 UTC

The Pagination Problem (and the can of worms it opened up)

Here''s the line of code that is now the bane of my existance:
@topic_pages, @topics = paginate(:topics, :include => :posts,
:order => ''posts.created_at asc'')

So, grab topics (eager loading the posts) and then order the topics
based on the post created date.

This doesn''t work because when paginate tries to count the records, it
-does- try to order them by posts.created_at but does not include
posts in the query.

I''d like to write some test cases and fix the bug, but interestingly
enough, there are no pagination tests in ActionPack. They just aren''t
there. In fact, if you ''grep -r "paginate" *'' in
your rails directory,
you won''t see any tests for pagination anywhere in the core.

I''m going to write the pagination tests I guess, since I need them now.

Unfortunately, I need an ActiveRecord connection in ActionPack in
order to test this. It seems that
test/active_record_assertions_test.rb needs AR as well, but the code
to connect is messy and localized to that file.

I''ve written a patch (http://dev.rubyonrails.org/ticket/3606)
extracting the ActiveRecord connection and fixture model loading (not
the data, which currently isn''t loaded in ActionPack either) to a
helper class.

All tests pass (without modifications) except two. These two
assertions are that the company model (defined in AR/fixtures) should
error out when rating = 2. This is residual from changeset #4
(http://dev.rubyonrails.org/browser/trunk/actionpack/test/controller/active_record_assertions_test.rb?rev=4)
so I''ve taken the liberty of writing a hacky setup/reset company
helper which is run in setup/teardown for the tests where it matters.
All tests now pass.

If anyone has widespread objections to this, please raise them ASAP.
I''d like to start writing pagination tests so I can fix my original
bug and want to base the connection code on my helper.

Jeremy Hopple

2006-Jan-25 23:36 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

Kevin,

I have written a patch[1] that addresses this issue, but it hasn''t
received
much attention.  I have also created a plugin[2] that makes eager loading
work via pagination.

I wrote new tests to verify the changes I made in ActiveRecord, but I never
wrote any tests for pagination... so it''s great that you wrote some. 
Maybe
we could get our patches reviewed as a pair.

Could someone please review this code?  I''ve had a few people use the
plugin
that wraps up this patch and been happy with it...

Thanks,
Jeremy

[1] http://dev.rubyonrails.org/ticket/2597
[2] http://wiki.rubyonrails.org/rails/pages/Count+Limit+Associations+Plugin


On 1/25/06, Kevin Clark <kevin.clark@gmail.com>
wrote:>
> Here''s the line of code that is now the bane of my existance:
>     @topic_pages, @topics = paginate(:topics, :include => :posts,
> :order => ''posts.created_at asc'')
>
> So, grab topics (eager loading the posts) and then order the topics
> based on the post created date.
>
> This doesn''t work because when paginate tries to count the
records, it
> -does- try to order them by posts.created_at but does not include
> posts in the query.
>
> I''d like to write some test cases and fix the bug, but
interestingly
> enough, there are no pagination tests in ActionPack. They just
aren''t
> there. In fact, if you ''grep -r "paginate" *''
in your rails directory,
> you won''t see any tests for pagination anywhere in the core.
>
> I''m going to write the pagination tests I guess, since I need them
now.
>
> Unfortunately, I need an ActiveRecord connection in ActionPack in
> order to test this. It seems that
> test/active_record_assertions_test.rb needs AR as well, but the code
> to connect is messy and localized to that file.
>
> I''ve written a patch (http://dev.rubyonrails.org/ticket/3606)
> extracting the ActiveRecord connection and fixture model loading (not
> the data, which currently isn''t loaded in ActionPack either) to a
> helper class.
>
> All tests pass (without modifications) except two. These two
> assertions are that the company model (defined in AR/fixtures) should
> error out when rating = 2. This is residual from changeset #4
> (
>
http://dev.rubyonrails.org/browser/trunk/actionpack/test/controller/active_record_assertions_test.rb?rev=4
> )
> so I''ve taken the liberty of writing a hacky setup/reset company
> helper which is run in setup/teardown for the tests where it matters.
> All tests now pass.
>
> If anyone has widespread objections to this, please raise them ASAP.
> I''d like to start writing pagination tests so I can fix my
original
> bug and want to base the connection code on my helper.
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Kevin Clark

2006-Jan-25 23:39 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

Jeremy,
Awesomeness. I''ll write up tests for pagination ASAP, but it''s
good to
see that my bug can be fixed with the plugin.

On the other hand it really shouldn''t require a plugin. Can someone
check out his code and check in?

Kev

On 1/25/06, Jeremy Hopple <jeremy@jthopple.com>
wrote:> Kevin,
>
>  I have written a patch[1] that addresses this issue, but it
hasn''t received
> much attention.  I have also created a plugin[2] that makes eager loading
> work via pagination.
>
>  I wrote new tests to verify the changes I made in ActiveRecord, but I
never
> wrote any tests for pagination... so it''s great that you wrote
some.  Maybe
> we could get our patches reviewed as a pair.
>
>  Could someone please review this code?  I''ve had a few people use
the
> plugin that wraps up this patch and been happy with it...
>
>  Thanks,
>  Jeremy
>
>  [1] http://dev.rubyonrails.org/ticket/2597
>  [2]
> http://wiki.rubyonrails.org/rails/pages/Count+Limit+Associations+Plugin
>
>
>
> On 1/25/06, Kevin Clark <kevin.clark@gmail.com> wrote:
> >
> > Here''s the line of code that is now the bane of my existance:
> >     @topic_pages, @topics = paginate(:topics, :include => :posts,
> > :order => ''posts.created_at asc'')
> >
> > So, grab topics (eager loading the posts) and then order the topics
> > based on the post created date.
> >
> > This doesn''t work because when paginate tries to count the
records, it
> > -does- try to order them by posts.created_at but does not include
> > posts in the query.
> >
> > I''d like to write some test cases and fix the bug, but
interestingly
> > enough, there are no pagination tests in ActionPack. They just
aren''t
> > there. In fact, if you ''grep -r "paginate"
*'' in your rails directory,
> > you won''t see any tests for pagination anywhere in the core.
> >
> > I''m going to write the pagination tests I guess, since I need
them now.
> >
> > Unfortunately, I need an ActiveRecord connection in ActionPack in
> > order to test this. It seems that
> > test/active_record_assertions_test.rb needs AR as well,
> but the code
> > to connect is messy and localized to that file.
> >
> > I''ve written a patch
> (http://dev.rubyonrails.org/ticket/3606)
> > extracting the ActiveRecord connection and fixture model loading (not
> > the data, which currently isn''t loaded in ActionPack either)
to a
> > helper class.
> >
> > All tests pass (without modifications) except two. These two
> > assertions are that the company model (defined in AR/fixtures) should
> > error out when rating = 2. This is residual from changeset #4
> >
>
(http://dev.rubyonrails.org/browser/trunk/actionpack/test/controller/active_record_assertions_test.rb?rev=4
> )
> > so I''ve taken the liberty of writing a hacky setup/reset
company
> > helper which is run in setup/teardown for the tests where it matters.
> > All tests now pass.
> >
> > If anyone has widespread objections to this, please raise them ASAP.
> > I''d like to start writing pagination tests so I can fix my
original
> > bug and want to base the connection code on my helper.
> > _______________________________________________
> > Rails-core mailing list
> > Rails-core@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-core
> >
>
>

Kevin Clark

2006-Jan-28 09:53 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

I''ve got a patch ready adding the pagination tests (and confirming the
bug with :include). It depends on ticket 3606
(http://dev.rubyonrails.org/ticket/3606) so I''ll submit it as soon as 
3606 is checked in.
Kev

On 1/25/06, Kevin Clark <kevin.clark@gmail.com>
wrote:> Jeremy,
> Awesomeness. I''ll write up tests for pagination ASAP, but
it''s good to
> see that my bug can be fixed with the plugin.
>
> On the other hand it really shouldn''t require a plugin. Can
someone
> check out his code and check in?
>
> Kev
>
> On 1/25/06, Jeremy Hopple <jeremy@jthopple.com> wrote:
> > Kevin,
> >
> >  I have written a patch[1] that addresses this issue, but it
hasn''t received
> > much attention.  I have also created a plugin[2] that makes eager
loading
> > work via pagination.
> >
> >  I wrote new tests to verify the changes I made in ActiveRecord, but I
never
> > wrote any tests for pagination... so it''s great that you
wrote some.  Maybe
> > we could get our patches reviewed as a pair.
> >
> >  Could someone please review this code?  I''ve had a few
people use the
> > plugin that wraps up this patch and been happy with it...
> >
> >  Thanks,
> >  Jeremy
> >
> >  [1] http://dev.rubyonrails.org/ticket/2597
> >  [2]
> >
http://wiki.rubyonrails.org/rails/pages/Count+Limit+Associations+Plugin
> >
> >
> >
> > On 1/25/06, Kevin Clark <kevin.clark@gmail.com> wrote:
> > >
> > > Here''s the line of code that is now the bane of my
existance:
> > >     @topic_pages, @topics = paginate(:topics, :include =>
:posts,
> > > :order => ''posts.created_at asc'')
> > >
> > > So, grab topics (eager loading the posts) and then order the
topics
> > > based on the post created date.
> > >
> > > This doesn''t work because when paginate tries to count
the records, it
> > > -does- try to order them by posts.created_at but does not include
> > > posts in the query.
> > >
> > > I''d like to write some test cases and fix the bug, but
interestingly
> > > enough, there are no pagination tests in ActionPack. They just
aren''t
> > > there. In fact, if you ''grep -r "paginate"
*'' in your rails directory,
> > > you won''t see any tests for pagination anywhere in the
core.
> > >
> > > I''m going to write the pagination tests I guess, since I
need them now.
> > >
> > > Unfortunately, I need an ActiveRecord connection in ActionPack in
> > > order to test this. It seems that
> > > test/active_record_assertions_test.rb needs AR as well,
> > but the code
> > > to connect is messy and localized to that file.
> > >
> > > I''ve written a patch
> > (http://dev.rubyonrails.org/ticket/3606)
> > > extracting the ActiveRecord connection and fixture model loading
(not
> > > the data, which currently isn''t loaded in ActionPack
either) to a
> > > helper class.
> > >
> > > All tests pass (without modifications) except two. These two
> > > assertions are that the company model (defined in AR/fixtures)
should
> > > error out when rating = 2. This is residual from changeset #4
> > >
> >
(http://dev.rubyonrails.org/browser/trunk/actionpack/test/controller/active_record_assertions_test.rb?rev=4
> > )
> > > so I''ve taken the liberty of writing a hacky setup/reset
company
> > > helper which is run in setup/teardown for the tests where it
matters.
> > > All tests now pass.
> > >
> > > If anyone has widespread objections to this, please raise them
ASAP.
> > > I''d like to start writing pagination tests so I can fix
my original
> > > bug and want to base the connection code on my helper.
> > > _______________________________________________
> > > Rails-core mailing list
> > > Rails-core@lists.rubyonrails.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails-core
> > >
> >
> >
>

Michael Koziarski

2006-Jan-29 09:38 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

On 1/28/06, Kevin Clark <kevin.clark@gmail.com>
wrote:> I''ve got a patch ready adding the pagination tests (and confirming
the
> bug with :include). It depends on ticket 3606
> (http://dev.rubyonrails.org/ticket/3606) so I''ll submit it as soon
as
> 3606 is checked in.
> Kev
As the original author, Sam''s probably the best guy to review any
tickets related to pagination.   Thanks for looking into its unit
tests too.

In the meantime,  I do have some questions about 3606.   The use of
37signals as a fixture name breaks instantiated fixtures as @37signals
is invalid,  that was a pretty simple fix though.

My main question is why the tests are defined in a huge block, it
feels a little strange to do

ActiveRecordTestRunner::Base::run(:companies) do
  ...
end

Rather than something like:

  class ActiveRecordAssertionsControllerTest < ActiveRecordTestCase
    self.fixture_path = "#{File.dirname(__FILE__)}/../fixtures/"
    fixtures :companies
  end

with ActiveRecordTestCase#setup taking care of the database connection/ cleanup.

Finally,  sorry for the fact that none of us got back to you, we all
appreciate your work on this.

--
Cheers

Koz

Kevin Clark

2006-Jan-29 10:00 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

Accidentally sent this just to Koz...

Also, I''ve been told that there is talk of refactoring Pagination all
together. I''m happy to take a shot at it. I tried to contact Sam on
IRC, but haven''t received a response.

--------------
> In the meantime,  I do have some questions about 3606.   The use of
> 37signals as a fixture name breaks instantiated fixtures as @37signals
> is invalid,  that was a pretty simple fix though.
Sorry, I can change it to something else.
>
> My main question is why the tests are defined in a huge block, it
> feels a little strange to do
>
> ActiveRecordTestRunner::Base::run(:companies) do
>   ...
> end
>
> Rather than something like:
>
>   class ActiveRecordAssertionsControllerTest < ActiveRecordTestCase
>     self.fixture_path = "#{File.dirname(__FILE__)}/../fixtures/"
>     fixtures :companies
>   end
The reason the runner is formed this way is that it is simply an
extraction. There was connection code in
active_record_assertions_test.rb. I refactored the code there to the
helper. I don''t disagree that more changes are needed. This was just
the quickest clean way to make things run and allow for reusable code.

I have completed the unit tests for pagination (excepting a test case
for singular_name as I don''t really understand what it is used for),
but am waiting to submit until I see how this patch works out.

Kev

Reply	Forward

Kevin Clark

2006-Jan-29 20:22 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

Oh, additionally, I don''t think the 37signals company breaks
instantiated fixtures as with my patch we''re only loading ActionPack
fixtures. Unless there are other ActionPack database fixtures I don''t
know about, I think we''re ok.

Kev

On 1/29/06, Kevin Clark <kevin.clark@gmail.com>
wrote:> Accidentally sent this just to Koz...
>
> Also, I''ve been told that there is talk of refactoring Pagination
all
> together. I''m happy to take a shot at it. I tried to contact Sam
on
> IRC, but haven''t received a response.
>
> --------------
>
> > In the meantime,  I do have some questions about 3606.   The use of
> > 37signals as a fixture name breaks instantiated fixtures as @37signals
> > is invalid,  that was a pretty simple fix though.
>
> Sorry, I can change it to something else.
>
> >
> > My main question is why the tests are defined in a huge block, it
> > feels a little strange to do
> >
> > ActiveRecordTestRunner::Base::run(:companies) do
> >   ...
> > end
> >
> > Rather than something like:
> >
> >   class ActiveRecordAssertionsControllerTest < ActiveRecordTestCase
> >     self.fixture_path =
"#{File.dirname(__FILE__)}/../fixtures/"
> >     fixtures :companies
> >   end
>
> The reason the runner is formed this way is that it is simply an
> extraction. There was connection code in
> active_record_assertions_test.rb. I refactored the code there to the
> helper. I don''t disagree that more changes are needed. This was
just
> the quickest clean way to make things run and allow for reusable code.
>
> I have completed the unit tests for pagination (excepting a test case
> for singular_name as I don''t really understand what it is used
for),
> but am waiting to submit until I see how this patch works out.
>
> Kev
>
> Reply   Forward
>

Kevin Clark

2006-Jan-30 09:06 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

Ok, my patch for ticket 3606 has been completely re-written. Now, if
you need to access ActiveRecord, you can do it by extending
ActiveRecordTestCase like so:

require ''active_record_unit''
require ''fixtures/post''
class PaginationTest < ActiveRecordTestCase
  fixtures :posts

  ...
end

It allows for localized (within ActionPack) fixtures and database
schemas and uses only one in memory database for all of the
ActiveRecordTestCase subclasses.

Koz and I have discussed what should happen to test cases when a
connection can''t be made for some reason, but we need to make a
choice. Right now, my code will report a connection problem and an
exception if one occured and then abort all the tests (within an
ActiveRecordTestCase) by redefining them with no bodies. Should this
be the behavior? Is there something better?

I''m also getting one bug that I could use some help trying to track
down. When you run a file or a collection of files with an
ActiveRecordTestCase, you get one failure: the default_test failure
for when no tests are defined.

By using printf debugging in the Test::Unit library itself
(Test::Unit::TestSuite#run), I''ve found that ActiveRecordTestCase is
run as a suite in addition to it''s subclass. Here''s a dump
that may
help:

SQLite 3 unavailable; falling to SQLite 2.
Loaded suite controller/active_record_assertions_test
Started
Running controller/active_record_assertions_test
Running ActiveRecordAssertionsControllerTest
....Running ActiveRecordTestCase
F
Finished in 0.242251 seconds.

  1) Failure:
default_test(ActiveRecordTestCase)
    [/usr/local/lib/ruby/1.8/test/unit/assertions.rb:30:in
`assert_block''
     /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`_wrap_assertion''
     /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`assert_block''
     /usr/local/lib/ruby/1.8/test/unit/assertions.rb:225:in `flunk''
     /usr/local/lib/ruby/1.8/test/unit/testcase.rb:99:in `default_test''
     /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in `__send__''
     /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in `run''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `each''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `each''
     /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run''
     /usr/local/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:44:in
`run_suite''
     /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:65:in
`start_mediator''
     /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:39:in
`start''
     /usr/local/lib/ruby/1.8/test/unit/ui/testrunnerutilities.rb:27:in
`run''
     /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:194:in `run''
     /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:14:in `run''
     /usr/local/lib/ruby/1.8/test/unit.rb:285
     /usr/local/lib/ruby/1.8/test/unit.rb:283]:
No tests were specified.

5 tests, 45 assertions, 1 failures, 0 errors


Thanks in advance,
Kev

Kevin Clark

2006-Jan-30 10:16 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

I just found a show stopper on this patch so I''ll be making further
modifications, but feel free to chime in if you have an opinion on our
choice or the bug described previously.
Kev

On 1/30/06, Kevin Clark <kevin.clark@gmail.com>
wrote:> Ok, my patch for ticket 3606 has been completely re-written. Now, if
> you need to access ActiveRecord, you can do it by extending
> ActiveRecordTestCase like so:
>
> require ''active_record_unit''
> require ''fixtures/post''
> class PaginationTest < ActiveRecordTestCase
>   fixtures :posts
>
>   ...
> end
>
> It allows for localized (within ActionPack) fixtures and database
> schemas and uses only one in memory database for all of the
> ActiveRecordTestCase subclasses.
>
> Koz and I have discussed what should happen to test cases when a
> connection can''t be made for some reason, but we need to make a
> choice. Right now, my code will report a connection problem and an
> exception if one occured and then abort all the tests (within an
> ActiveRecordTestCase) by redefining them with no bodies. Should this
> be the behavior? Is there something better?
>
> I''m also getting one bug that I could use some help trying to
track
> down. When you run a file or a collection of files with an
> ActiveRecordTestCase, you get one failure: the default_test failure
> for when no tests are defined.
>
> By using printf debugging in the Test::Unit library itself
> (Test::Unit::TestSuite#run), I''ve found that ActiveRecordTestCase
is
> run as a suite in addition to it''s subclass. Here''s a
dump that may
> help:
>
> SQLite 3 unavailable; falling to SQLite 2.
> Loaded suite controller/active_record_assertions_test
> Started
> Running controller/active_record_assertions_test
> Running ActiveRecordAssertionsControllerTest
> ....Running ActiveRecordTestCase
> F
> Finished in 0.242251 seconds.
>
>   1) Failure:
> default_test(ActiveRecordTestCase)
>     [/usr/local/lib/ruby/1.8/test/unit/assertions.rb:30:in
`assert_block''
>      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`_wrap_assertion''
>      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`assert_block''
>      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:225:in
`flunk''
>      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:99:in
`default_test''
>      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in
`__send__''
>      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `each''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `each''
>      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:44:in
> `run_suite''
>      /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:65:in
> `start_mediator''
>      /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:39:in
`start''
>      /usr/local/lib/ruby/1.8/test/unit/ui/testrunnerutilities.rb:27:in
`run''
>      /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:194:in `run''
>      /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:14:in `run''
>      /usr/local/lib/ruby/1.8/test/unit.rb:285
>      /usr/local/lib/ruby/1.8/test/unit.rb:283]:
> No tests were specified.
>
> 5 tests, 45 assertions, 1 failures, 0 errors
>
>
> Thanks in advance,
> Kev
>

Kevin Clark

2006-Jan-30 10:34 UTC

head link

Re: The Pagination Problem (and the can of worms it opened up)

I think there are issues with making all of this an extension of
Test::Unit::TestCase instead of the big block I originally extracted.
Namely that we have all sorts of issues with requiring files and using
the fixtures method in TestCase''s and not catching the errors that
will occur if ActiveRecord isn''t at the same level as ActionPack. I
keep hacking at code, but the only thing I think might work is massive
if then statements in the test code for if ActiveRecord is loaded,
which is ugly and problematic.

Can someone think of a better way to do this or a way that will work?
I''m beginning to think that the block syntax from before version 5 of
the patch may be the only way to make this work.

Kev

On 1/30/06, Kevin Clark <kevin.clark@gmail.com>
wrote:> I just found a show stopper on this patch so I''ll be making
further
> modifications, but feel free to chime in if you have an opinion on our
> choice or the bug described previously.
> Kev
>
> On 1/30/06, Kevin Clark <kevin.clark@gmail.com> wrote:
> > Ok, my patch for ticket 3606 has been completely re-written. Now, if
> > you need to access ActiveRecord, you can do it by extending
> > ActiveRecordTestCase like so:
> >
> > require ''active_record_unit''
> > require ''fixtures/post''
> > class PaginationTest < ActiveRecordTestCase
> >   fixtures :posts
> >
> >   ...
> > end
> >
> > It allows for localized (within ActionPack) fixtures and database
> > schemas and uses only one in memory database for all of the
> > ActiveRecordTestCase subclasses.
> >
> > Koz and I have discussed what should happen to test cases when a
> > connection can''t be made for some reason, but we need to make
a
> > choice. Right now, my code will report a connection problem and an
> > exception if one occured and then abort all the tests (within an
> > ActiveRecordTestCase) by redefining them with no bodies. Should this
> > be the behavior? Is there something better?
> >
> > I''m also getting one bug that I could use some help trying to
track
> > down. When you run a file or a collection of files with an
> > ActiveRecordTestCase, you get one failure: the default_test failure
> > for when no tests are defined.
> >
> > By using printf debugging in the Test::Unit library itself
> > (Test::Unit::TestSuite#run), I''ve found that
ActiveRecordTestCase is
> > run as a suite in addition to it''s subclass. Here''s
a dump that may
> > help:
> >
> > SQLite 3 unavailable; falling to SQLite 2.
> > Loaded suite controller/active_record_assertions_test
> > Started
> > Running controller/active_record_assertions_test
> > Running ActiveRecordAssertionsControllerTest
> > ....Running ActiveRecordTestCase
> > F
> > Finished in 0.242251 seconds.
> >
> >   1) Failure:
> > default_test(ActiveRecordTestCase)
> >     [/usr/local/lib/ruby/1.8/test/unit/assertions.rb:30:in
`assert_block''
> >      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`_wrap_assertion''
> >      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:28:in
`assert_block''
> >      /usr/local/lib/ruby/1.8/test/unit/assertions.rb:225:in
`flunk''
> >      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:99:in
`default_test''
> >      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in
`__send__''
> >      /usr/local/lib/ruby/1.8/test/unit/testcase.rb:70:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in
`each''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in
`each''
> >      /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:32:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:44:in
> > `run_suite''
> >      /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:65:in
> > `start_mediator''
> >      /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:39:in
`start''
> >      /usr/local/lib/ruby/1.8/test/unit/ui/testrunnerutilities.rb:27:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:194:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:14:in
`run''
> >      /usr/local/lib/ruby/1.8/test/unit.rb:285
> >      /usr/local/lib/ruby/1.8/test/unit.rb:283]:
> > No tests were specified.
> >
> > 5 tests, 45 assertions, 1 failures, 0 errors
> >
> >
> > Thanks in advance,
> > Kev
> >
>

Rails core - Jan 2006 - The Pagination Problem (and the can of worms it opened up)

The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)

Re: The Pagination Problem (and the can of worms it opened up)