Forum: Rails-ES paginate_by_sql

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
89e28c7d17e0309cf4e4ddbbf6d1f701?d=identicon&s=25 Jaime Iniesta (Guest)
on 2007-04-02 16:01
(Received via mailing list)
Hola!

Tengo una lista [1] paginada con el método tradicional (paginate), pero
me gustaría poder ordenarla por un campo que no está directamente en el
modelo paginado. Me explico. Estoy listando paginados los "watchers",
que a su vez están enlazados con las "paginas" a través de pagina_id.
Son las paginas las que tienen los campos "address" y "pagerank", así
que en este listado se muestra en plan

<% for watcher in @watchers %>

    <%= watcher.pagina.address %> - <%= watcher.pagina.pagerank %>
<br />

<% end %>

Total, que me gustaría ordenar el listado por watcher.pagina.address o
watcher.pagina.pagerank pero paginate solo me permitirá ordenarlo por
campos del modelo watcher...

Por lo que he visto, para esto existe paginate_by_sql [2], pero no forma
parte de Rails, así que lo tengo que incorporar a mi aplicación... ¿Es
así? ¿Existe una solución mejor?

Gracias!

[1] http://www.pagerankalert.com/watchers/list
[2]
http://thebogles.com/blog/2006/06/paginate_by_sql-...
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2007-04-02 17:28
(Received via mailing list)
On 4/2/07, Jaime Iniesta <jaime@railes.net> wrote:
> <% for watcher in @watchers %>
> parte de Rails, así que lo tengo que incorporar a mi aplicación... ¿Es así?
> ¿Existe una solución mejor?
>
> Gracias!
>
> [1] http://www.pagerankalert.com/watchers/list
> [2]
> http://thebogles.com/blog/2006/06/paginate_by_sql-...
>

No lo he probado pero me imagino que funcionará; si al find le metes un
include podrías ordenar por un campo del otro modelo (aunque no podrás
usar
el clásico paginate, creo, sí podrás usar el método aún más clásico de
instanciar el Paginator. Algo como

Watcher.find(:all, :include => :pagina, :order => 'paginas.address',
...)

Cuéntanos si funciona =;-)
03060587b9dd45470d7b704ba3345241?d=identicon&s=25 Marze (Guest)
on 2007-04-02 23:30
(Received via mailing list)
hay unos cuantos plugins y tutoriales por ahí

yo me quedo con éste
http://errtheblog.com/post/929

pero estos también tienen su puntillo
http://weblog.jamisbuck.org/2007/2/28/poor-man-s-pagination
http://www.igvita.com/blog/2006/09/22/eager-find-b...
rails/
http://cardboardrocket.com/2006/09/06/paginating-f...

depende de lo que busques
si eres más arriesgado puede probar a hacer una paginación infinita
de esas
como la de humanized.com en su apartado de human feed reader

un saludo!
marze


El 02/04/2007, a las 15:59, Jaime Iniesta escribió:
89e28c7d17e0309cf4e4ddbbf6d1f701?d=identicon&s=25 Jaime Iniesta (Guest)
on 2007-04-03 00:10
(Received via mailing list)
Gracias Sergio, Marze...

Finalmente lo he hecho según [1] y funciona dabutismente.

Jaimes

[1]
http://thebogles.com/blog/2006/06/paginate_by_sql-...


El lun, 02-04-2007 a las 23:29 +0200, Marze escribió:
Fc3f12c165eaeac4999bc274215fb582?d=identicon&s=25 Roberto m. Oliva (roliva)
on 2007-04-03 12:17
(Received via mailing list)
Hola a todos!

Estamos desarrollando un proyecto en rails de un tamaño que empieza a
ser considerable. Para los testeos (tanto unitarios como funcionales)
estamos utilizando las fixtures y me estan surgiendo una serie de dudas
filosoficas, a ver que opiniones teneis al respecto.

En otros proyectos que he desarrollado (en .NET) he realizado los
testeos siguiendo estos pasos por cada testeo (nada nuevo):
1- Base de datos vacia
2- Carga de datos requeridos por el testo.
3- Ejecucion de la funcionalidad a testear
4- Comprobacion del resultado de la funcionalidad.

La idea es que yo preparo los datos para asegurarme el resultado del
testeo. Con lo que consigo, entre otras cosas: Testeos aislados
(requisito fundamental del TDD) y logica del testeo minima (si hacemos
una logica grande nos puede fallar y eso es lo peor que nos puede
pasar... a no ser que testeemos el testeo ;) ).
Por ejemplo, voy a testear una funcion que me devuelva los clientes que
haya en una tabla:
1- Base de datos vacia
2- Meto dos clientes en la tabla
3- Ejecuto la funcion.
4- Compruebo que me devuelve 2 clientes y que tienen los datos
esperados.

Como se ve la comprobacion es minima en cuanto a funcionalidad.
Con esta aproximacion he realizado proyectos basados en TDD con
resultados muy satisfactorios.

Por otro lado, estan lo que utiliza Rails que son los fixtures. Por lo
que he leido entiendo a las fixtures como una mini base de datos de la
aplicacion sobre la que hacer testeos. Esto tiene la ventaja de que
facilita mucho la entrada de datos en la base de datos. Pero complica
muchisimo la comprobacion de los datos ya que los testeos no son
aislados. Esto hace que la comprobacion no presupone nada sobre el
estado inicial de los datos, hay que realizar funcionalidad de testeos
para saber que el resultado requerido es correcto. Siguiendo los
ejemplos anteriores se seguiria un proceso como el siguiente utilizando
fixtures:
1- Base de datos vacias
2- Meto fixtures (por ejemplo 2 clientes)
3- Ejecuto la funcion a testear
4a- Consulto el numero de clientes que hay en la base de datos
4b- Compruebo que el punto 3 y el punto 4a me devuelve lo mismo.

Porque hay que hacerlo asi? Porque nadie me impide, por que lo necesite
para otro testeo, el incluir uno o mas clientes en la lista.

Resumiendo (perdonad por el tocho que os he escrito, pero creo que es
una teoria interesante para todos) las fixtures no apoyan el aislamiento
de los testeos, mas bien lo perjudican... eso, o es que las estamos
orientando mal.

Nos ayudais? Que opinion teneis al respecto?

Muchas gracias!!!
Roberto M. Oliva
89e7c8b162c71e9905fbfe7d2ec376dc?d=identicon&s=25 Fernando Blat (ferblape)
on 2007-04-05 11:28
(Received via mailing list)
Hola Roberto,

la verdad es que yo soy muy joven, y eso unido a las carencias del
plan de estudios de Ingeniero Informático en la Politécnica de
Valencia, han hecho que yo no supiera nada de testing de software
hasta que vi que lo hacía Ruby on Rails.

Así que digamos, que yo he aprendido de testing tomando como base
sóloRuby on Rails.

Como bien dices, las fixtures son una ayuda de Rails para probar datos
en el entorno de testing, y en cada test tendremos una serie de
fixtures que hayamos definido. Por lo menos yo, le veo más ventajas de
las que tú planteas:

- tener datos ya precargados te ahorra tener que insertarlos cada vez
que quieras realizar una consulta, con lo cuál sólo lo haces una vez
para toda la suite de test y no te repites (DRY famoso) y evitas
errores, etc

- también te permite gestionar los datos de test de forma que puedas
ir incluyendo nuevos datos según avanza el desarrollo del proyecto,
sin tener que modificar luego todas tus funciones. Esto es muy
útilpara añadir casos excepcionales, que siempre surgen cuando la
funcionalidad ya está desarrollada.

- (pon aquí tu ventaja).

Y por último, comentar que no resulta tan problemático lo de tener ya
datos para testear la inserción de nuevos datos, por ejemplo
utilizando el helper assert_difference(Model, :count, n) que comprueba
que se hayan insertado n objetos, siendo n un entero tanto positivo
como negativo.

Conclusión, y perdona la piedra de e-mail: que lo de las fixtures no
resulta problemático, sino que puede llegar a ser una ventaja si te
acostumbras a ello.

Y si no te acostumbras, siempre puedes ejecturar un borrado de todos
los objetos del modelo antes de ejecutar el test :)

Un saludo.
73d1f44915bc63152981588dd879ed98?d=identicon&s=25 Roberto M. Oliva (Guest)
on 2007-04-09 10:42
(Received via mailing list)
Hola Fernando!

Gracias por tu ladrillo (que no lo es tanto). Nosotros empezamos
planteando
las fixtures precisamente porque veia las ventajas que tu comentas.
Sobre
todo el que los datos son mas logicos organizados en fixtures que
insertados
"a mano".
El problema nos ha surgido cuando ha ido creciendo el numero de modelos
en
la aplicación. Ha llegado un momento en que una modificacion en las
fixtures
para contemplar las novedades hacia que rompiesen muchos otros testeos
tanto
por la logica (que puede ser normal) como por la funcionalidad de los
testeos (esto es lo que mas complica el tema).
Queria contestaciones como la tuya, porque ya tengo algo que investigar:
assert_difference(Model, :count, n)
Y aprovecho para hacerte una pregunta... En los testeos que tu haces,
como
los evaluas? Contra valores fijos? Consultas la base de datos para
comparar
lo devuelto por la funcionalidad?

Muchas gracias por tu ayuda
Un saludo
Roberto M. Oliva


-----Mensaje original-----
De: Fernando Blat [mailto:ferblape@gmail.com]
Enviado el: jueves, 05 de abril de 2007 11:27
Para: roliva@idecnet.com; La lista sobre Ruby On Rails (rubyonrails.com)
en
castellano
Asunto: Re: [Ror-es] A vueltas con las fixtures

Hola Roberto,

la verdad es que yo soy muy joven, y eso unido a las carencias del plan
de
estudios de Ingeniero Informático en la Politécnica de Valencia, han hecho
que yo no supiera nada de testing de software hasta que vi que lo
hacía Ruby
on Rails.

Así que digamos, que yo he aprendido de testing tomando como base sólo Ruby
on Rails.

Como bien dices, las fixtures son una ayuda de Rails para probar datos
en el
entorno de testing, y en cada test tendremos una serie de fixtures que
hayamos definido. Por lo menos yo, le veo más ventajas de las que tú
planteas:

- tener datos ya precargados te ahorra tener que insertarlos cada vez
que
quieras realizar una consulta, con lo cuál sólo lo haces una vez para toda
la suite de test y no te repites (DRY famoso) y evitas errores, etc

- también te permite gestionar los datos de test de forma que puedas ir
incluyendo nuevos datos según avanza el desarrollo del proyecto, sin tener
que modificar luego todas tus funciones. Esto es muy útil para añadir casos
excepcionales, que siempre surgen cuando la funcionalidad ya está
desarrollada.

- (pon aquí tu ventaja).

Y por último, comentar que no resulta tan problemático lo de tener ya datos
para testear la inserción de nuevos datos, por ejemplo utilizando el helper
assert_difference(Model, :count, n) que comprueba que se hayan insertado
n
objetos, siendo n un entero tanto positivo como negativo.

Conclusión, y perdona la piedra de e-mail: que lo de las fixtures no
resulta
problemático, sino que puede llegar a ser una ventaja si te acostumbras a
ello.

Y si no te acostumbras, siempre puedes ejecturar un borrado de todos los
objetos del modelo antes de ejecutar el test :)

Un saludo.

On 4/3/07, Roberto M. Oliva <roliva@idecnet.com> wrote:
> 2- Carga de datos requeridos por el testo.
> 1- Base de datos vacia
> que he leido entiendo a las fixtures como una mini base de datos de la
> 2- Meto fixtures (por ejemplo 2 clientes)
> las estamos orientando mal.
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>


--
Fernando Blat
blog > http://www.inwebwetrust.net
89e7c8b162c71e9905fbfe7d2ec376dc?d=identicon&s=25 Fernando Blat (ferblape)
on 2007-04-09 11:58
(Received via mailing list)
Claro, es que muchas veces el problema es hacer un test lo suficiente
genérico como para que te sirva aunque vayas modificando datos y
fixtures.

Un buen truco es hacer, siempre que se pueda, algo como esto:

obj = Class.find(1)

Y utilizar los atributos de obj para todo, por ejemplo para las urls:

get :edit, :id => obj.id

O para comprobar literales, etc

Es difícil y a pesar de todo los tests son bastante poco genéricos,
pero bueno, mejor eso que llenarlo todo de literales, y que cuando
cambias uno, tienes que cambiarlos todos.

Espero que te sirva. Un saludo!!!
75cf3e99d398f414c227a63bcdb46b51?d=identicon&s=25 Fernando García Samblas (Guest)
on 2007-04-09 14:51
(Received via mailing list)
Roberto M. Oliva
escribió:> [...] Queria contestaciones como la tuya, porque ya tengo algo que 
investigar:
> assert_difference(Model, :count, n)
>

cuidado, assert_difference no es (a día de hoy) un helper de Rails.
Nosotros (Blat, otros compañeros en the-cocktail y yo) estamos usándolo
desde hace mucho tiempo pero en realidad nos lo trajo el "login
generator".


> De: Fernando Blat [mailto:ferblape@gmail.com]
> on Rails.
> la suite de test y no te repites (DRY famoso) y evitas errores, etc
> assert_difference(Model, :count, n) que comprueba que se hayan insertado n
>
>> testeos siguiendo estos pasos por cada testeo (nada nuevo):
>> Por ejemplo, voy a testear una funcion que me devuelva los clientes
>>
>> fixtures:
>> una teoria interesante para todos) las fixtures no apoyan el
>>
> blog > http://www.inwebwetrust.net
>
> _______________________________________________
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>
>


--
Fernando García Samblas
fernando.garcia@the-cocktail.com

The Cocktail
C/ Salamanca 17
28020 Madrid
+34 91 567 06 05
This topic is locked and can not be replied to.