Hola a todos. ¿Alguien sabe de un tutorial o sitio donde pueda encontrar
información completa sobre las posibilidades de :conditions y las
búsquedas
en general?
Por lo pronto querÃa averiguar como podria buscar por negación, es decir
‘where not id=valor’.
Gracias.
On 10/10/2007, Rafa C. [email protected] wrote:
Hola a todos. ¿Alguien sabe de un tutorial o sitio donde pueda encontrar
información completa sobre las posibilidades de :conditions y las búsquedas
en general?
:conditions acepta simplemente fragmentos de SQL. ¿Qué quieres decir
con “las posibilidades de”?
Por lo pronto quería averiguar como podria buscar por negación, es decir
‘where not id=valor’.
¿La pregunta es cuál es el operador de negación en SQL? En ANSI SQL es
<>, aunque la mayoría de los RDBMS aceptan !=, creo.
–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o http://simplelogica.net/logicola/
Recuerda comer mucha fruta y verdura.
On 10/10/07, Manuel González Noriega [email protected]
wrote:
On 10/10/2007, Rafa C. [email protected] wrote:
Hola a todos. ¿Alguien sabe de un tutorial o sitio donde pueda encontrar
información completa sobre las posibilidades de :conditions y las búsquedas
en general?:conditions acepta simplemente fragmentos de SQL. ¿Qué quieres decir
con “las posibilidades de”?
Bueno, en realidad hoy también acepta un Hash, que para filtros simple
es mucho más lindo:
Post.find(:all, :conditions => {:author_id => 1, :created_on =>
Date.today…Date.today - 5})
Esto genera una consulta del tipo SELECT * FROM posts WHERE author_id
= 1 AND created_on BETWEEN … AND …
Por lo pronto quería averiguar como podria buscar por negación, es decir
‘where not id=valor’.
En este caso:
Post.find(:all, :conditions => [‘id != ?’, valor_indeseado])
El Array de conditions contiene como primer elemento toda la cadena de
SQL a insertar en el WHERE, y el resto de los elementos son los
valores a reemplazar por los placeholders (“?”).
Saludos
Ok, yo creÃa que se podÃa hacer con hashes de alguna forma, oper
ejemplo,
despues de mandar el correo se me ocurrió que a lo mejor
:conditions =>{ :not => { :id=> x , ...} }
podrÃa funcionar. O igualmente podrÃa haber algo como
:conditions =>{ :like => { :name=> x}, :sql_in =>{ :id => [ id1,
id2…
] } }
que parece muy ‘a lo Rails’. Pero ya estaba con la oreja en la almohada
y no
era el momento.
Yo es que habÃa leÃdo hace poco que el sistema de sustitución de ‘?’ era
peligroso porque permitÃa inyectar SQL, pero supongo que es que ahora
mismo
no hay otra forma.
saludos y gracias.
Yo es que había leído hace poco que el sistema de sustitución de ‘?’ era
peligroso porque permitía inyectar SQL,
Esto no es correcto. La especificación de condiciones con array o con
hash es completamente segura. Podéis revisar la doc. de rails:
http://api.rubyonrails.com/classes/ActiveRecord/Base.html
(sección “Conditions”)
On Oct 11, 2007, at 9:39 AM, Rafa C. wrote:
Ok, yo creía que se podía hacer con hashes de alguna forma, oper
ejemplo, despues de mandar el correo se me ocurrió que a lo mejor:conditions =>{ :not => { :id=> x , ...} }podría funcionar. O igualmente podría haber algo como
:conditions =>{ :like => { :name=> x}, :sql_in =>{ :id =>[ id1, id2… ] } }
No lo uso, pero hay un plugin que ofrece algo parecido:
http://agilewebdevelopment.com/plugins/ez_where
– fxn
On 11/10/2007, Rafa C. [email protected] wrote:
Ok, yo creía que se podía hacer con hashes de alguna forma, oper ejemplo,
despues de mandar el correo se me ocurrió que a lo mejor
Sí, está todo en la documentación de find.
:conditions =>{ :not => { :id=> x , ...} }podría funcionar. O igualmente podría haber algo como
:conditions =>{ :like => { :name=> x}, :sql_in =>{ :id => [ id1, id2...] } }
que parece muy ‘a lo Rails’. Pero ya estaba con la oreja en la almohada y no
era el momento.
A mi estas cosas me parecen anti-Rails porque complican todo para no
ganar nada. O sea, estás reescribiendo una sentencia SQL sencillita en
Ruby de una forma que a mi me parece bastante ilegible 
Yo es que había leído hace poco que el sistema de sustitución de ‘?’ era
peligroso porque permitía inyectar SQL, pero supongo que es que ahora mismo
no hay otra forma.
No, te has liado. Lo que se dice es que esa sintaxis te protege de
la inyección SQL. Es decir, este método, que “esteriliza” las
variables a interpolar, es el que debes usar.
–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o http://simplelogica.net/logicola/
Recuerda comer mucha fruta y verdura.
On 11/10/2007, Damian J. [email protected] wrote:
On 10/10/07, Manuel González Noriega [email protected] wrote:
:conditions acepta simplemente fragmentos de SQL. ¿Qué quieres decir
con “las posibilidades de”?Bueno, en realidad hoy también acepta un Hash, que para filtros simple
es mucho más lindo:
Sí, mi respuesta no fue completa. La verdad es que suelo utilizar
siempre el array con SQL e interpolación y casi había olvidado la
forma del hash, la verdad.
Puedo defenderme diciendo que como, con RJS, me pongo un poco nervioso
cuando Rails intenta tapar del todo el resto de capas, prefiero que
asome algo por debajo de la chapa para que la gente no se olvide
(sobre todo los que empiezan a desarrollar web con Rails) del resto de
tecnologías y variables a tener en cuenta. Pero también puede ser
simplemente que esté mayor
–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o http://simplelogica.net/logicola/
Recuerda comer mucha fruta y verdura.
On 10/11/07, Manuel González Noriega [email protected]
wrote:
Puedo defenderme diciendo que como, con RJS, me pongo un poco nervioso
cuando Rails intenta tapar del todo el resto de capas, prefiero que
asome algo por debajo de la chapa para que la gente no se olvide
(sobre todo los que empiezan a desarrollar web con Rails) del resto de
tecnologías y variables a tener en cuenta. Pero también puede ser
simplemente que esté mayor
Depende del uso.
La forma del hash me permite combinar condiciones muy fácilmente. Si
tengo un finder que utiliza la forma del hash, es fácil enviarle
condiciones adicionales vía #merge.
Igual estoy de acuerdo en que “tapar por tapar” no tiene sentido. Las
propuestas de hacer algo como {:name_like => ‘foo’,
:date_of_birth_less_than => Date.today} tampoco me gustan.
Intentos como ez_where o Ambition [1] me parecen buenísimos (yo
empecé a hacer uno también y es muy divertido). No esconden el SQL
sino que directamente lo eliminan. Proveen una API 100% Ruby:
User.select { |u| [1, 2, 3, 4].include? u.id }
Así, hasta se podría pensar en un motor que decide si algunas
consultas se ejecutan sobre la base de datos, o si es algo simple que
lo puede resolver Ruby (si tengo un caché en memoria de todos los
usuarios, o si es una asociación cargada y simplemente hay que
filtrarla, etc.)
On Oct 11, 2007, at 11:03 AM, Manuel González Noriega wrote:
era el momento.
A mi estas cosas me parecen anti-Rails porque complican todo para no
ganar nada. O sea, estás reescribiendo una sentencia SQL sencillita en
Ruby de una forma que a mi me parece bastante ilegible
+1
On Oct 11, 2007, at 2:34 PM, Damian J. wrote:
Depende del uso.
La forma del hash me permite combinar condiciones muy fácilmente. Si
tengo un finder que utiliza la forma del hash, es fácil enviarle
condiciones adicionales vía #merge.
Agreed, la forma builtin con hash la encuentro clara. Ademas de lo
que apuntas es un idioma parecido a los que entienden #new, #create,
etc. Por el mismo precio ademas soluciona el SQL para NULLs. Porque
hay que tener presente que cuando escribes
:conditions => [“foo = ?”, foo]
asumes que foo no es nil, si pudiera serlo ese codigo no es correcto
para ese caso. La forma hash genera “foo IS NULL” si es necesario.
Una de las cosas que mas me gustaron de AR cuando lo vi por primera
vez fue que tomaba un punto medio que comparto. A medio camino entre
el SQL a pelo y una ida de olla de encapsulacion. Es una capa fina
pero muy conveniente a la practica en mi opinion.
Tambien es verdad lo que dice Damian, una capa por encima podria ser
que no solo trate la expresividad, sino que ofrezca otras ventajas,
en ese caso habria que ver.
– fxn
On 10/11/07, Rafa C. [email protected] wrote:
Yo la ventaja que veo a hacer una capa SQL es la ocultación de nombres (por
llamarle algo), el poner el nombre del campo en una variable, de forma que
si cambias el nombre del campo, no tienes que cambiarlo en todos los sitios
donde lo usas porque esta escondido bajo la variable. Sin embargo, lo normal
es que la variable se llame igual que el campo, y como los nombres de
variable están generados por el framework, cuando cambias el nomber del
campo se cambia también el de la variable. Lo bueno (al menos en Java) es
que al cambiar el nomber el compilador dará error en todos los sitios donde
se usaba el nombre antíguo, en lugar de saltar esos errores en tiempo de
ejecución.
El error salta cuando corres los tests 
Yo la ventaja que veo a hacer una capa SQL es la ocultación de nombres
(por
llamarle algo), el poner el nombre del campo en una variable, de forma
que
si cambias el nombre del campo, no tienes que cambiarlo en todos los
sitios
donde lo usas porque esta escondido bajo la variable. Sin embargo, lo
normal
es que la variable se llame igual que el campo, y como los nombres de
variable están generados por el framework, cuando cambias el nomber del
campo se cambia también el de la variable. Lo bueno (al menos en Java)
es
que al cambiar el nomber el compilador dará error en todos los sitios
donde
se usaba el nombre antÃguo, en lugar de saltar esos errores en tiempo de
ejecución.
ah, el maravilloso y aún desconocido para mà mundo de los tests…
un dÃa de estos aprenderé a usarlos.
Hola,
Yo la ventaja que veo a hacer una capa SQL es la ocultación de nombres
(por llamarle algo), el poner el nombre del campo en una variable, de
forma que si cambias el nombre del campo, no tienes que cambiarlo en
todos los sitios donde lo usas porque esta escondido bajo la variable.
Sin embargo, lo normal es que la variable se llame igual que el campo,
y como los nombres de variable están generados por el framework,
cuando cambias el nomber del campo se cambia también el de la
variable. Lo bueno (al menos en Java) es que al cambiar el nomber el
compilador dará error en todos los sitios donde se usaba el nombre
antíguo, en lugar de saltar esos errores en tiempo de ejecución.
Lo malo en java es que una vez cambies el nombre del campo en tu código,
tendrás que modificarlo en todos los mappings que hayas definido o, en
el mejor de los casos, modificar las anotaciones y regenerar los
ficheros de configuración. Eso está tan sujeto a errores como la
modificación del nombre de la variable es la misma. En los dos casos,
Rails y Config de Java, con un grep lo arreglas.
Además, en el caso de Rails, los IDEs empiezan a ser cada vez más
potentes en cosas como el Refactoring y aunque todavía no están al nivel
de lenguajes con comprobación estática de tipos, ya van siendo muy
interesantes. Podrías simplemente desde tu IDE seleccionar el nombre del
campo y darle a refactorizar (que entiendo es lo mismo que harías en
java, a no ser que prefieras ir recorriéndote los errores uno a uno para
cambiarlos)
Al final cada enfoque para la capa de persistencia tiene sus ventajas y
sus inconvenientes.Yo el enfoque de capa de mapping al estilo de
JDO/Hibernate lo veo muy potente, muy conceptual, muy desacoplado y muy
interesante para cierto tipo de aplicaciones, mientras que una capa de
wrapping como ActiveRecord la veo mucho más acoplada desde el punto de
vista de diseño, pero mucho más ágil y que en la vida real funciona bien
en un porcentaje muy alto de los casos, en concreto en el tipo de base
de datos que se usan en la web.
saludos,
javier ramirez
en el environment.rb …
$KCODE = ‘u’
quizas?
El dÃa 11/10/07, salvador zalapa [email protected] escribió:
Hola, tengo un problemin que en mi aplicacion los mensajes de flash[],
no
me muestra los acentos sino caracteres raros, en mi template ya tengo
y es raro por que el resto de la información si me muestra los acentos bien
solo en el flash[] no.
Agradezco comentarios gracias!
Windows Live Spaces en Prodigy/MSN Spaces: Crea tu propio espacio.
http://spaces.live.com
On 10/11/07, salvador zalapa [email protected] wrote:
Nop ya lo tenia as� y no funciona, pero gracias
El encoding de tus archivos .rb es utf-8?
Ha si ahi esta el error lo que pasa es que migré la aplicacion de linux a
windows y la estaba editando en notpad, muchas fracias Damian.
El encoding de tus archivos .rb es utf-8?
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
¿ Ya tienes la última versión de Messenger?
www.imagine-msn.com/messenger/launch80/default.aspx?locale=es-mx Windows
Live Messenger en Prodigy/MSN
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs