Discussion:
MySQL insertar datos en una tabla, error
(too old to reply)
Pablo Graff
2009-07-07 03:09:25 UTC
Permalink
Hola a todos:
Les quería preguntar si es correcto la forma en la cual ingreso los datos
en una tabla de una BD MySQL y si es que hay mas formas porque leyendo y
recorriendo la web encontre mucha data de conectarse con una BD MySQL pero
no mucho de insertar datos y mucho menos explicado, aca les dejo un solo
codigo que me anda y dos por los cuales consulto.-


v_id=raw_input("Ingrese el id: ")
v_nombre=raw_input("Ingrese el Nombre: ")
v_apellido=raw_input("Ingrese el Apellido: ")
v_email=raw_input("Ingrese el e-mail: ")

db=MySQLdb.connect(host=host,user=user, passwd=passwd,db=db)
cursor=db.cursor()

#esta sentencia si anda!!!
#sql='INSERT INTO clientes VALUES ("%s","%s","%s","%s")'%( v_id , v_nombre ,
v_apellido , v_email)
cursor.execute(sql)


Pero esta otra no....!!! por que no le puedo indicar en que campo es donde
quiero ingresar los datos?, solo por inquietud ya que de la otra forma me
anda, pero quería saber el porque, osea cual es la diferencia entre decirle
("%s","%s","%s","%s") y decirle ( id_cliente , Nombre , Apellido , email )
que son los campos de la tabla...

sql='INSERT INTO clientes VALUES ( id_cliente , Nombre , Apellido , email
)'% ( v_id , v_nombre , v_apellido , v_email)
cursor.execute(sql)

El error que me muestra es:

Traceback (most recent call last):
File "/home/pablo/Escritorio/insert_mysql_py (copia).py", line 29, in
<module>
sql='INSERT INTO clientes VALUES ( id_cliente , Nombre , Apellido ,
email )'% ( v_id , v_nombre , v_apellido , v_email)
TypeError: not all arguments converted during string formatting

Tambien no podria ser algo asi? Tampoco me anda!!!
sql='INSERT INTO clientes ( id_cliente , Nombre , Apellido , email ) VALUES
( v_id , v_nombre , v_apellido , v_email)'

Desde ya muchas gracias.-
Juanjo Conti
2009-07-07 04:01:12 UTC
Permalink
El 7 de julio de 2009 00:09, Pablo
Post by Pablo Graff
sql='INSERT INTO clientes VALUES ( id_cliente , Nombre , Apellido , email
)'% ( v_id , v_nombre , v_apellido , v_email)
cursor.execute(sql)
  File "/home/pablo/Escritorio/insert_mysql_py (copia).py", line 29, in
<module>
    sql='INSERT INTO clientes VALUES ( id_cliente , Nombre , Apellido ,
email )'% ( v_id , v_nombre , v_apellido , v_email)
TypeError: not all arguments converted during string formatting
Es

sql='INSERT INTO clientes VALUES ( %s , %s , %s , %s)' % ( v_id ,
v_nombre , v_apellido , v_email)
Post by Pablo Graff
Tambien no podria ser algo asi? Tampoco me anda!!!
sql='INSERT INTO clientes ( id_cliente , Nombre , Apellido , email ) VALUES
( v_id , v_nombre , v_apellido , v_email)'
o

sql='INSERT INTO clientes ( id_cliente , Nombre , Apellido , email )
VALUES (%s, %s, %s, %s)' % ( v_id , v_nombre , v_apellido , v_email)

Contesté de memoria, pero probá, debe alcanzar para que te des cuenta del error.

Saludos!
--
Juanjo Conti
John Rowland Lenton
2009-07-07 11:48:15 UTC
Permalink
Post by Juanjo Conti
sql='INSERT INTO clientes VALUES ( %s , %s , %s , %s)' % ( v_id ,
v_nombre , v_apellido , v_email)
por favor no hagas eso. Nunca, nunca, nunca. Todos los conectores que
siguen la dbapi2 (osea, todos) tienen un método para hacer eso que son
mucho más seguros. Hay distintos; el atributo 'paramstyle' del módulo
Post by Juanjo Conti
import psycopg
psycopg.paramstyle
'pyformat'
Post by Juanjo Conti
import MySQLdb
MySQLdb.paramstyle
'format'

pueden ver lo que quieren decir estos valores en
http://www.python.org/dev/peps/pep-0249/

pero básicamente con MySQLdb hacés

sql = 'bla bla %s %s'
cursor.execute(sql, (param1, param2))
Juanjo Conti
2009-07-07 14:31:23 UTC
Permalink
El 7 de julio de 2009 08:48, John Rowland
Post by John Rowland Lenton
Post by Juanjo Conti
sql='INSERT INTO clientes VALUES ( %s , %s , %s , %s)' % ( v_id ,
v_nombre , v_apellido , v_email)
por favor no hagas eso. Nunca, nunca, nunca. Todos los conectores que
siguen la dbapi2 (osea, todos) tienen un método para hacer eso que son
mucho más seguros.
Totalmente de acuerdo. Quise ayudar con el error de formateo de string
y no pensé en esto.

Saludos,
--
Juanjo Conti
Pablo Graff
2009-07-07 19:03:20 UTC
Permalink
Hola compañeros Pytonistas:

Les agradezco a todos por sus ayudas y comentarios, es que en verdad tengo
tantas ganas de aprender y programar con Python que no llevo un orden en las
lecturas, ejemplos y ya los intento volcar a un código... Lo que estoy
viendo son varios tutoriales a la ves de Python, pero hasta el momento no
encontré el manual del programador de Python o algo asi por llamarlo de esa
forma "Su Biblia".-

En cuanto a sus preguntas o comentarios, para:

Gabriel: Las v_ de comienzo de las variables las arrastro de Visual Fox Pro
9, que es una forma de cuando lea el código las pueda identificar con el
tipo correspondiente a lo que pertenecen.-

Y [1] como me lo acotaste vos no, nunca escuche de “sql injection”

José Luis: Gracias, no hay problema, no me ofendo así no mas, te comento
que como digo mas arriba yo vengo de Visual Fox Pro 9 y existen "dos formas"
(que conozco por lo menos) de generar consultas a BD sean las propias de fox
para DBF o conexiones a MySQL de forma a “la Fox” o con sentencias MySQL,
las cuales una forma sencilla de insertar seria...

USE BD_CLIENTES

INSERT INTO clientes (id,nombre,apellido) VALUES (“1”,Jorge,Lopez)

y ahora al ver ejemplos en la web de códigos de Python y MySQL más de uno
sin idea de el por que se pone de una forma o de otra, quiero que te
imagines vos la la cantidad de formas que probé sin tener idea también de lo
que estaba poniendo, la verdad mucha info en los tutos que leí no existía, y
otra cosa no termino de acostumbrarme todavía a programar de la forma a lo
de Python, es un cambio realmente grande del que vengo, ahora encontré
también otro código que también me anda pero me gustaría saber donde leer
los porque...

lo que no me acostumbro es a:

sql='INSERT INTO clientes VALUES (%s,%s,%s,%s)'

cursor.execute(sql, (id,nombre, apellido,e_mail))


el que me aparezca %s y no entienda que es lo que signifique (el símbolo,
obvio que me doy cuenta que se refiere a una posición en la tabla), ya que
por ejemplo al no poder elegir el campo en el que quiero ingresar un dato
tengo que imaginarme cual es el numero del campo al que quiero ingresar para
poder poner un %s por cada campo anterior a esta para poder llegar a el? Y
si solo quisiera ingresar datos en un solo campo con %s como hago para
elegir el campo?

Otro código que también me resulto fue:

cursor.execute('INSERT INTO clientes ( id_cliente , Nombre , Apellido ,
email ) VALUES (%s,%s,%s,%s)',( v_id , v_nombre , v_apellido , v_email))

no siendo de la misma manera el resultado para:

sql='INSERT INTO clientes ( id_cliente , Nombre , Apellido , email ) VALUES
(%s,%s,%s,%s)',( v_id , v_nombre , v_apellido , v_email)

cursor.execute(sql)

tampoco se el porque?, este ultimo no me anda!!!


Disculpen por lo extenso de mi comentario pero quería ayudarlos a que me
entiendan para que me puedan ayudar a mi también.- Desde ya muchas gracias a
todos


Pablo.-
Matigro
2009-07-07 19:40:01 UTC
Permalink
El 7 de julio de 2009 16:03, Pablo
Post by Pablo Graff
el que me aparezca %s y no entienda que es lo que signifique
eso significa que en ese posición, lo que venga, lo transforme en string
... print("te llamas %s, y tienes %s años" % (nombre, edad))
...
Post by Pablo Graff
presentacion('Matias', 31)
te llamas Matias, y tienes 31 años
Post by Pablo Graff
presentacion(31, 'Matias')
te llamas 31, y tienes Matias años

Como todo lo que le paso lo transforma a string, también lo hace con
los años, que debería ser númerales.
... print("te llamas %s, y tienes %d años" % (nombre, edad))
...
Post by Pablo Graff
presentacion('Matias', 31)
te llamas Matias, y tienes 31 años
Post by Pablo Graff
presentacion(31, 'Matias')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in presentacion
TypeError: int argument required
¿Sa antandió?
--
http://www.linkedin.com/in/matigro
Jose Luis Dallapiccola
2009-07-07 20:25:56 UTC
Permalink
Hola Pablo :-D
Post by Gabriel Genellina
sql='INSERT INTO clientes VALUES (%s,%s,%s,%s)'
cursor.execute(sql, (id,nombre, apellido,e_mail))
Así sería la forma de hacerlo. execute se encarga de reemplazar el
primer %s con el valor de id (primer parámetro), el segundo %s con
nombre (segundo parámetro), el tercer %s con apellido y el cuarto %s
con e_mail. Asimismo se encarga de manejar "cosas" como adecuar los
valores a los tipos de datos esperados. Por ejemplo nombre seguramente
es un char en la base de datos.
Post by Gabriel Genellina
el que me aparezca %s y no entienda que es lo que signifique (el símbolo,
obvio que me doy cuenta que se refiere a una posición en la tabla), ya que
por ejemplo al no poder elegir el campo en el que quiero ingresar un dato
tengo que imaginarme cual es el numero del campo al que quiero ingresar para
poder poner un %s por cada campo anterior a esta para poder llegar a el? Y
si solo quisiera ingresar datos en un solo campo con %s como hago para
elegir el campo?
cursor.execute('INSERT INTO clientes ( id_cliente , Nombre , Apellido ,
email ) VALUES (%s,%s,%s,%s)',( v_id , v_nombre , v_apellido , v_email))
Es similar a la forma anterior que mencionás.
Post by Gabriel Genellina
sql='INSERT INTO clientes ( id_cliente , Nombre , Apellido , email ) VALUES
(%s,%s,%s,%s)',( v_id , v_nombre , v_apellido , v_email)
cursor.execute(sql)
tampoco se el porque?, este ultimo no me anda!!!
Es muy probable que este código no te funcione de la manera que esperás.
Primero es que deberías entrecomillar los valores textuales como el
nombre, apellido, email.
Segundo: Así no se debería hacer, sería muy vulnerable al "SQL injection".

Aun si quisieras hacerlo así debería ser similar a lo siguiente
(supongo que id_cliente es numérico y el resto son texto):

sql = 'INSERT INTO clientes (id_cliente, Nombre, Apellido, email)
VALUES (%s, "%s", "%s", "%s")' % (v_id, v_nombre, v_apellido, v_email)
cursor.execute(sql)
Post by Gabriel Genellina
Disculpen por lo extenso de mi comentario pero quería ayudarlos a que me
entiendan para que me puedan ayudar a mi también.- Desde ya muchas gracias a
todos
Pablo.-
Saludos,
--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina
Sebastian Bassi
2009-07-08 21:17:48 UTC
Permalink
Post by John Rowland Lenton
pero básicamente con MySQLdb hacés
sql = 'bla bla %s %s'
cursor.execute(sql, (param1, param2))
El otro dia justo aprendi que en sqlite es:

t = (param1,param2)
c.execute("insert into cleanseqs values (?,?)",t)

o siguiendo tu nomenclatura:

sql = 'bla bla ? ?'
cursor.execute(sql, (param1, param2))

Ahora mirando tu mail veo "la big picture' y me doy cuenta que tendria
Post by John Rowland Lenton
sqlite3.paramstyle
'qmark'

Para ver que lo que me propuso Alex Martelli está mal y porque me da este error:
sqlite3.InterfaceError: Error binding parameter :t - probably unsupported type.
Ver aca:
http://stackoverflow.com/questions/1005552/sqlite-parameter-substitution-and-quotes
Gabriel Genellina
2009-07-08 23:35:23 UTC
Permalink
En Wed, 08 Jul 2009 18:17:48 -0300, Sebastian Bassi
2009/7/7 John Rowland Lenton
Post by John Rowland Lenton
pero básicamente con MySQLdb hacés
sql = 'bla bla %s %s'
cursor.execute(sql, (param1, param2))
sql = 'bla bla ? ?'
cursor.execute(sql, (param1, param2))
Ahora mirando tu mail veo "la big picture' y me doy cuenta que tendria
Post by John Rowland Lenton
sqlite3.paramstyle
'qmark'
sqlite3.InterfaceError: Error binding parameter :t - probably
unsupported type.
http://stackoverflow.com/questions/1005552/sqlite-parameter-substitution-and-quotes
En mi opinión, los que definieron la DB-API 2.0 fueron medio debiluchos.
Deberían haberse puesto más fuertes y definir UN estilo de parametros que
todos los adaptadores deberían soportar; otro estilo "nativo", si queres,
puede ser opcional.
Porque ahora esta todo muy lindo y muy portable entre bases de datos pero
a la hora de hacer un sql con parámetros estás atado a un tipo de marcas
en particular, y si cambias de base de datos, hay que cambiar todos los
sql.
No es nada nuevo, les pasó al comite que definio el SQL92, al que
estandarizó Ethernet...
--
Gabriel Genellina
Hernan Olivera
2009-07-08 23:49:04 UTC
Permalink
Yo me pregunto: no es mas 'pythonico' usar un ORM

Digo, ya que se empieza con Python, empezar a disfrutar las ventajas

(sin intenciones de flame)
En Wed, 08 Jul 2009 18:17:48 -0300, Sebastian Bassi <
pero básicamente con MySQLdb hacés
Post by Sebastian Bassi
Post by John Rowland Lenton
sql = 'bla bla %s %s'
cursor.execute(sql, (param1, param2))
sql = 'bla bla ? ?'
cursor.execute(sql, (param1, param2))
Ahora mirando tu mail veo "la big picture' y me doy cuenta que tendria
Post by John Rowland Lenton
sqlite3.paramstyle
Post by Sebastian Bassi
'qmark'
sqlite3.InterfaceError: Error binding parameter :t - probably unsupported type.
http://stackoverflow.com/questions/1005552/sqlite-parameter-substitution-and-quotes
En mi opinión, los que definieron la DB-API 2.0 fueron medio debiluchos.
Deberían haberse puesto más fuertes y definir UN estilo de parametros que
todos los adaptadores deberían soportar; otro estilo "nativo", si queres,
puede ser opcional.
Porque ahora esta todo muy lindo y muy portable entre bases de datos pero a
la hora de hacer un sql con parámetros estás atado a un tipo de marcas en
particular, y si cambias de base de datos, hay que cambiar todos los sql.
No es nada nuevo, les pasó al comite que definio el SQL92, al que
estandarizó Ethernet...
--
Gabriel Genellina
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/
--
Hernan Olivera
Pablo Ziliani
2009-07-09 01:16:25 UTC
Permalink
Post by Hernan Olivera
Yo me pregunto: no es mas 'pythonico' usar un ORM
Considerando que un ORM es una abstracción que permite escribir
consultas un lenguaje distinto del SQL, y asumiendo que ese lenguaje es
Python, sí, definitívamente es muho más pythónico.

Aunque usar un ORM esté buenísimo y sea la mejor elección para resolver
la mayoría de los problemas que se discuten en esta lista, la
"pythonicidad" puede también ser la excusa ideal del vago y del "mago de
un sólo truco" (título que ostento en más de una actividad).

La elección correcta entre escribir SQL "a pelo" o usar un ORM también
depende del uso concreto que se le vaya a dar. El caso más obvio es
cuando el programa a desarrollar es en sí mismo un ORM, pero hay
muchísimos casos más para los que poner un alien entre la base de datos
y tu código o no tiene sentido, o es desaconsejable.

Por ejemplo, por performance. No tengo datos concretos, pero sí el
recuerdo de hace unos 3 o 4 años, cuando noté que un sitio hecho en
CakePHP [que nunca me animaré a poner en mi portfolio] hacía cientos de
consultas para mostrar 1 (una) página que "normalmente" hubieran podido
resolverse en menos de 5 consultas (sin siquiera optimizarlas
demasiado). Más allá de lo particular de *esa* página, el punto es que
hay condiciones en las que diferencias de órdenes similares son relevantes.
Post by Hernan Olivera
Digo, ya que se empieza con Python, empezar a disfrutar las ventajas
Como sugerencia está perfecta, pero tampoco se puede invalidar cualquier
uso de SQL, particularmente sin conocer el contexto de aplicación real.
Post by Hernan Olivera
(sin intenciones de flame)
Claramente. Pero al hacer top-posting rompiste el orden de la
conversación y ahora la gente no sabe a qué le estabas respondiendo.
Chaschás para Hernán que no leyó la etiqueta de PyAr[1]


Abrazo,
Pablo

[1] http://python.org.ar/pyar/EtiquetaPyAr
Hernan Olivera
2009-07-09 15:42:49 UTC
Permalink
Post by Hernan Olivera
Yo me pregunto: no es mas 'pythonico' usar un ORM
Considerando que un ORM es una abstracción que permite escribir consultas
un lenguaje distinto del SQL, y asumiendo que ese lenguaje es Python, sí,
definitívamente es muho más pythónico.
Aunque usar un ORM esté buenísimo y sea la mejor elección para resolver la
mayoría de los problemas que se discuten en esta lista, la "pythonicidad"
puede también ser la excusa ideal del vago y del "mago de un sólo truco"
(título que ostento en más de una actividad).
La elección correcta entre escribir SQL "a pelo" o usar un ORM también
depende del uso concreto que se le vaya a dar. El caso más obvio es cuando
el programa a desarrollar es en sí mismo un ORM, pero hay muchísimos casos
más para los que poner un alien entre la base de datos y tu código o no
tiene sentido, o es desaconsejable.
Por ejemplo, por performance. No tengo datos concretos, pero sí el recuerdo
de hace unos 3 o 4 años, cuando noté que un sitio hecho en CakePHP [que
nunca me animaré a poner en mi portfolio] hacía cientos de consultas para
mostrar 1 (una) página que "normalmente" hubieran podido resolverse en menos
de 5 consultas (sin siquiera optimizarlas demasiado). Más allá de lo
particular de *esa* página, el punto es que hay condiciones en las que
diferencias de órdenes similares son relevantes.
Si, está claro. De hecho, tengo en mente rehacer un sistema que tiene
algunas sql de 30 lineas, y me pregunto si podre hacer eso razonablemente
con un ORM.
Digo, ya que se empieza con Python, empezar a disfrutar las ventajas
Como sugerencia está perfecta, pero tampoco se puede invalidar cualquier
uso de SQL, particularmente sin conocer el contexto de aplicación real.
de acuerdo
(sin intenciones de flame)
Claramente. Pero al hacer top-posting rompiste el orden de la conversación
y ahora la gente no sabe a qué le estabas respondiendo.
Chaschás para Hernán que no leyó la etiqueta de PyAr[1]
Mea culpa, pero sí la leí. Se que rompe la norma, pero a veces creo que hay
casos en los que se podría justificar. En este caso mi comentario no
derivaba de todo lo que le habian dicho, sino que retomaba la pregunta
original. Tal vez debí escribirla contestando a ese mensaje. A veces me
parece que cuando es apenas un comentario, una sola linea o dos, y no
necesariamente tiene que ir al final de una argumentación previa para que se
entienda, es un poco mas económico no tener que bajar todo el mensaje para
leerlo. Casi casi que es una respuesta al subject.
Pero si, es top posting, mil disculpas a los puristas, me hago cargo, y si
es cierto que rompe la continuidad.
Ponganme las amonestaciones nomas.
Abrazo,
Pablo
[1] http://python.org.ar/pyar/EtiquetaPyAr
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/
--
Hernan Olivera
Pablo Ziliani
2009-07-09 16:40:30 UTC
Permalink
Hola Hernán,


*Según lo veo yo*, escribir antes de las citas hace más amena la lectura
para las presentaciones/salutaciones (ej.: "Hola Hernán") o cuando se
quiere recontextualizar a una conversación. Esto se puede hacer antes (a
modo de preámbulo) o después (como conclusión), según el estilo del
autor. Habrá otras razones, pero de una u otra forma se busca preservar
la separación entre el diálogo que se viene llevando y el monólogo que
se quiere incorporar.
Post by Pablo Ziliani
(...)
Chaschás para Hernán que no leyó la etiqueta de PyAr[1]
Mea culpa, pero sí la leí. Se que rompe la norma, pero a veces creo
que hay casos en los que se podría justificar.
Claro que sí.
Post by Pablo Ziliani
En este caso mi comentario no derivaba de todo lo que le habian dicho,
sino que retomaba la pregunta original. Tal vez debí escribirla
contestando a ese mensaje.
Y, sí...
Post by Pablo Ziliani
A veces me parece que cuando es apenas un comentario, una sola linea o
dos, y no necesariamente tiene que ir al final de una argumentación
previa para que se entienda, es un poco mas económico no tener que
bajar todo el mensaje para leerlo. Casi casi que es una respuesta al
subject.
Yendo más lejos, hay veces en las que ni siquiera hace falta responder
(no digo que sea tu caso). Pero incluso una "respuesta al subject" es
una respuesta al email original, si no, estás respondiendo al NUEVO
subject (que empieza con "Re: "), es decir, donde el asunto es *la
respuesta* al asunto original.
Post by Pablo Ziliani
Pero si, es top posting, mil disculpas a los puristas, me hago cargo,
y si es cierto que rompe la continuidad.
Ponganme las amonestaciones nomas.
¿Amonestaciones? ¡diez meses de trabajo forzado escribiendo ABMs en
VisualBasic!
Agravado por no haber borrado todo esto en la justificación (antento
Post by Pablo Ziliani
Abrazo,
Pablo
[1] http://python.org.ar/pyar/EtiquetaPyAr
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/
Lo importante es que sepas que más allá del chiste no es grave, y en
cambio sí es una oportunidad para que los nuevos integrantes de la lista
vayan incorporando esa cajita de herramientas que es para mejorar la
comunicación la etiqueta que supimos conseguir.

...que supiiiiiimos con-se-guir.


Un abrazo,
Pablo Torquemada
Ernesto Savoretti
2009-07-09 16:57:16 UTC
Permalink
Post by Pablo Ziliani
¿Amonestaciones? ¡diez meses de trabajo forzado escribiendo ABMs en
VisualBasic!
Noooo. Eso es crueldad agravada, alevosía y que se yo cuántas cosas
más. Hasta Torquemada hubiese sido más compasivo.
Buscar algo más benigno, por favor. Por ejemplo llenarle los bolsillos
de dinero y tirarlo a un pozo lleno de abogados...
--
Ernesto Savoretti
Lucas Favaloro
2009-07-11 19:41:22 UTC
Permalink
Una pregunta, yo tengo el server wampp instalado en la pc, sirve igual para
practicas de coneccion a BD
Post by Hernan Olivera
Post by Hernan Olivera
Yo me pregunto: no es mas 'pythonico' usar un ORM
Considerando que un ORM es una abstracción que permite escribir consultas
un lenguaje distinto del SQL, y asumiendo que ese lenguaje es Python, sí,
definitívamente es muho más pythónico.
Aunque usar un ORM esté buenísimo y sea la mejor elección para resolver la
mayoría de los problemas que se discuten en esta lista, la "pythonicidad"
puede también ser la excusa ideal del vago y del "mago de un sólo truco"
(título que ostento en más de una actividad).
La elección correcta entre escribir SQL "a pelo" o usar un ORM también
depende del uso concreto que se le vaya a dar. El caso más obvio es cuando
el programa a desarrollar es en sí mismo un ORM, pero hay muchísimos casos
más para los que poner un alien entre la base de datos y tu código o no
tiene sentido, o es desaconsejable.
Por ejemplo, por performance. No tengo datos concretos, pero sí el
recuerdo de hace unos 3 o 4 años, cuando noté que un sitio hecho en CakePHP
[que nunca me animaré a poner en mi portfolio] hacía cientos de consultas
para mostrar 1 (una) página que "normalmente" hubieran podido resolverse en
menos de 5 consultas (sin siquiera optimizarlas demasiado). Más allá de lo
particular de *esa* página, el punto es que hay condiciones en las que
diferencias de órdenes similares son relevantes.
Si, está claro. De hecho, tengo en mente rehacer un sistema que tiene
algunas sql de 30 lineas, y me pregunto si podre hacer eso razonablemente
con un ORM.
Digo, ya que se empieza con Python, empezar a disfrutar las ventajas
Como sugerencia está perfecta, pero tampoco se puede invalidar cualquier
uso de SQL, particularmente sin conocer el contexto de aplicación real.
de acuerdo
(sin intenciones de flame)
Claramente. Pero al hacer top-posting rompiste el orden de la conversación
y ahora la gente no sabe a qué le estabas respondiendo.
Chaschás para Hernán que no leyó la etiqueta de PyAr[1]
Mea culpa, pero sí la leí. Se que rompe la norma, pero a veces creo que hay
casos en los que se podría justificar. En este caso mi comentario no
derivaba de todo lo que le habian dicho, sino que retomaba la pregunta
original. Tal vez debí escribirla contestando a ese mensaje. A veces me
parece que cuando es apenas un comentario, una sola linea o dos, y no
necesariamente tiene que ir al final de una argumentación previa para que se
entienda, es un poco mas económico no tener que bajar todo el mensaje para
leerlo. Casi casi que es una respuesta al subject.
Pero si, es top posting, mil disculpas a los puristas, me hago cargo, y si
es cierto que rompe la continuidad.
Ponganme las amonestaciones nomas.
Abrazo,
Pablo
[1] http://python.org.ar/pyar/EtiquetaPyAr
---------------------------------------------------------------------
PyAr - Python Argentina - Sitio web: http://www.python.com.ar/
--
Hernan Olivera
Jose Luis Dallapiccola
2009-07-12 15:35:27 UTC
Permalink
Hola.
Post by Hernan Olivera
Yo me pregunto: no es mas 'pythonico' usar un ORM
Digo, ya que se empieza con Python, empezar a disfrutar las ventajas
No siempre es necesario un ORM. Creo que todo depende del contexto, es
conveniente conocer SQL (y hacer pequeñas prácticas) antes de pasar a
DBAPI o un ORM.


Saludos,
--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina
Ernesto Savoretti
2009-07-07 05:30:08 UTC
Permalink
Les quería preguntar si es correcto la forma en la cual  ingreso los datos
en una tabla de una BD MySQL y si es que hay mas formas porque leyendo y
recorriendo la web encontre mucha data de conectarse con una BD MySQL pero
no mucho de insertar datos y mucho menos explicado, aca les dejo un solo
codigo que me anda y dos por los cuales consulto.-
v_id=raw_input("Ingrese el id: ")
v_nombre=raw_input("Ingrese el Nombre: ")
v_apellido=raw_input("Ingrese el Apellido: ")
v_email=raw_input("Ingrese el e-mail: ")
db=MySQLdb.connect(host=host,user=user, passwd=passwd,db=db)
cursor=db.cursor()
#esta sentencia si anda!!!
#sql='INSERT INTO clientes VALUES ("%s","%s","%s","%s")'%( v_id , v_nombre ,
v_apellido , v_email)
cursor.execute(sql)
a ver.... en el ejemplo anterior, print sql daría:

"INSERT INTO clientes VALUES("el_id_que_pusiste",
"el_nombre_que_pusiste", "el_apellido_que_pusiste",
"el_mail_que_pusiste")

lo cual es una sentencia:
1) válida para Python
2) válida para el motor de BD.
Pero esta otra no....!!! por que no le puedo indicar en que campo es donde
quiero ingresar los datos?, solo por inquietud ya que de la otra forma me
anda, pero quería saber el porque, osea cual es la diferencia entre decirle
("%s","%s","%s","%s") y decirle ( id_cliente , Nombre , Apellido , email )
que son los campos de la tabla...
sql='INSERT INTO clientes VALUES ( id_cliente , Nombre , Apellido , email
)'% ( v_id , v_nombre , v_apellido , v_email)
cursor.execute(sql)
en este caso:
1) No es una sentencia Python válida. Fijate bien lo que te tira el
trace: no estás construyendo un string válido
2) en el supuesto de que fuese válida para el intérprete Python, no lo
sql='INSERT INTO clientes FIELDS ( id_cliente , Nombre , Apellido , email
) VALUES ("%s","%s","%s","%s")' % ( v_id , v_nombre , v_apellido , v_email)
hint: fijate FIELDS y VALUES. Eso tiene que ver con la sintaxis SQL.

Espero que te sirva.
--
Ernesto Savoretti
Gabriel Genellina
2009-07-07 06:12:29 UTC
Permalink
En Tue, 07 Jul 2009 00:09:25 -0300, Pablo Graff
Post by Pablo Graff
v_id=raw_input("Ingrese el id: ")
v_nombre=raw_input("Ingrese el Nombre: ")
v_apellido=raw_input("Ingrese el Apellido: ")
v_email=raw_input("Ingrese el e-mail: ")
db=MySQLdb.connect(host=host,user=user, passwd=passwd,db=db)
cursor=db.cursor()
#esta sentencia si anda!!!
#sql='INSERT INTO clientes VALUES ("%s","%s","%s","%s")'%( v_id , v_nombre ,
v_apellido , v_email)
cursor.execute(sql)
Pero es un buraco de seguridad asi de grande [1], aparte de hacer las
cosas mas complicadas de lo necesario. Dejá que el adaptador de la base de
datos se ocupe de hacer las conversiones de formato que convengan. La
forma de escribirlo sería:

sql='INSERT INTO clientes VALUES (%s,%s,%s,%s)'
cursor.execute(sql, (v_id, v_nombre, v_apellido, v_email))

Conviene pensar que %s es sólo una marca (no un formato) que dice dónde
hay que poner el valor correspondiente.
Fijate que cursor.execute recibe DOS parametros: la sentencia SQL con sus
marcas, y los valores a reemplazar.

De paso, ese v_ de los nombres tiene algún motivo especial, o es sólo
lastre que te viene de algún otro lenguage...?

[1] Si nunca oíste hablar de "sql injection":
http://xkcd.com/327/
--
Gabriel Genellina
Jose Luis Dallapiccola
2009-07-07 14:24:55 UTC
Permalink
Hola Pablo.

Primero, sin intentar ofender, creo que deberías aprender un poco de
SQL antes de intentar utilizarlo con algún lenguaje como por ejemplo
python.

Para esto podrías consultar:
http://es.wikipedia.org/wiki/SQL
http://es.wikipedia.org/wiki/SQL_injection (esto ya Gabriel lo ha mencionado)
http://dev.mysql.com/doc/refman/5.0/es/insert.html (documentación
específica de MySQL)

Luego de esto ya podrías ver cómo utilizar INSERT y DB-API en python.
http://www.python.org/dev/peps/pep-0249/ (Un poco complicado, pero
creo que de lectura obligada)
http://python.org.ar/pyar/DbApi (Nuestra documentación!)
http://mundogeek.net/archivos/2008/06/25/bases-de-datos-en-python/
http://blog.calcifer.com.ar/2009/03/26/accediendo-a-mysql-con-python-y-mysqldb/
http://www.linux-itt.com/2008/08/python-manejo-de-bases-de-datos.html

Lo que te permite DB-API es que te puedas conectar y utilizar de
manera similar distintos motores de base de datos.

Bueno, no más por ahora :-D
Exitos.
--
---
José Luis DALLAPICCOLA
Neuquén Capital
Patagonia Argentina
Continue reading on narkive:
Loading...