Reserva de autoincremento

leac3 · #1 (**permalink**) 21/04/2011, 17:41

Hola, estoy haciendo una webapp supersencilla a nivel de usuario, lo esoterico esta en saber antes de insertar la informacion, cual es el ID que va a tener dicho registro. Obviamente el campo ID es un primary key con autoincremento.

La forma de buscar cual es el ultimo ID y sumarle 1 no me sirve, ya que la aplicacion es multiusuario, es decir estara en internet, y mientras hago un SELECT para conocer ese ultimo ID, ya otro usuario puede estar haciendo lo mismo, y habria incosistencia.

Es por ello que necesito saber si existe alguna forma de hacer esto de forma atomica.

Gracias de antemano, y saludos a todos los miembros de esta comunidad, de verdad que es la mejor.

anrodse · #2 (**permalink**) 21/04/2011, 17:50

Si tu tabla tiene algun campo unico, que no se vaya a repetir, esta la opcion de que una vez hayas hecho la inserccion, hagas una consulta donde selecciones el ID para la tupla insertada.

Espero que esto te sirva. yo lo he hecho, pero no siempre es válido esto

leac3 · #3 (**permalink**) 21/04/2011, 20:17

Cita:

Iniciado por anrodse

Si tu tabla tiene algun campo unico, que no se vaya a repetir, esta la opcion de que una vez hayas hecho la inserccion, hagas una consulta donde selecciones el ID para la tupla insertada.

Espero que esto te sirva. yo lo he hecho, pero no siempre es válido esto

Si, se que con SELECT last_insert_id() obtengo el ultimo autoincrement que generó el DBMS. Pero eso en un sistema de alto trafico puede generar incosistencias.

Es por ello que ando en busca de alguna forma avanzada del SQL que me permita hacerlo de forma atomica.

A no ser que MySQL no tenga esas capacidades y Oracle si.

gnzsoloyo · #4 (**permalink**) 21/04/2011, 20:37

Tienes que usar tablas InnoDB, de ese modo podrás usar transacciones (además de soportar restricciones de FK).
Si usas tablas MyISAM no podrás hacer nada.

PD: Eso lo podrías haber averiguado con sólo consultar el manual de referencia: MySQL AB MySQL 5.0 Reference Manual o usar Google con la pregunta adecuada: transacciones en MySQL

leac3 · #5 (**permalink**) 22/04/2011, 09:24

Cita:

Iniciado por gnzsoloyo

Tienes que usar tablas InnoDB, de ese modo podrás usar transacciones (además de soportar restricciones de FK).
Si usas tablas MyISAM no podrás hacer nada.

PD: Eso lo podrías haber averiguado con sólo consultar el manual de referencia: MySQL AB MySQL 5.0 Reference Manual o usar Google con la pregunta adecuada: transacciones en MySQL

uhm ok, si, se que tiene algo que ver con transacciones pero no se que buscar ya que no estoy muy informado del tema como ya dije. Antes de acudir a este foro, siempre acudo antes a Google, por eso he de venir aqui, a los que saben; y buscar Transacciones en MySQL en Google, creo que es un tema como que muy amplio para un caso tan especifico como el mio.

gnzsoloyo · #6 (**permalink**) 22/04/2011, 09:52

Cita:

creo que es un tema como que muy amplio para un caso tan especifico como el mio.

El problema es que precisamente tu problema está inscripto completamente en el tema transacciones.
Haciendo una visión simple, cuando declaras una transacción todas las sentencias DML de tipo INSERT/UPDATE/DELETE entran como condicionales, lo que quiere decir que los cambios producidos a las tablas no existen en forma definitiva hasta que la transacción completa no se confirma. Además, toda operación DML de un usuario concurrente queda en espera hasta que la transacción que usa las tablas no termine (confirmada o cancelada). Las´únicas operaciones accesibles son los SELECT, los cuales a su vez son inseguros hasta el final, por lo que ciertas cosas deben ser reconfirmadas cuando se liberan.
Como los autoincrementales son parte de este proceso, el uso de transacciones es una forma segura de resolver tu problema. Con el uso de tablas InnoDB el tema de la "próxima clave" tiene un capítulo propio en el Manual de referencia: MySQL Reference Manual::15.10.6. Bloqueo de la próxima clave (Next-Key Locking): evitar el problema fantasma. El método descripto creo que es suficientemente simple para que lo uses...

leac3 · #7 (**permalink**) 22/04/2011, 10:54

eso es, gracias gnzsoloyo, ahora si me convencistes de leer ese tema, gracias, para alla voy.

HackmanC · #8 (**permalink**) 22/04/2011, 10:54

Hola,

Cita:

Iniciado por leac3

... estoy haciendo una webapp supersencilla a nivel de usuario, lo esoterico esta en saber antes de insertar la informacion, cual es el ID que va a tener dicho registro. ...

Aplicación Web ... allí está el problema realmente. No hay base de datos que tenga esa capacidad (ni Oracle) porque la transacción se va a realizar en dos pasos en un tiempo futuro indeterminado. Posiblemente lo puedes hacer con J2EE transaccional con Enterprise Java Beans o .NET con conexiones por sesión.

Que es lo que pasa ...

1. El usuario solicita la página.
2. El servidor devuelve la página. (En este momento se calcula el proximo ID).

3. El servidor y el usuario se desconectan completamente.

4. El usuario envía la página con los datos solicitados.
5. El servidor actúa consecuentemente.
6. El servidor devuelve la respuesta.

El 'gap' está en el paso 3, no se puede mantener una transacción abierta en ese lapso de tiempo sin recurrir a servidores que tengan persistencia de conexiones por sesión o algo parecido. Si recuperas el ID en el paso 5 solamente para que cliente lo apunte, entonces no necesitas nada solamente realiza el INSERT y recupera el last_insert_id.

Saludos,

ps:

El problema es muy complicado, pero con las descripciones que das no se te puede ayudar correctamente. Por ejemplo, no dijiste porqué motivo quieres saber el número con antelación, posiblemente hay otros métodos si te tomas la molestia de explicar detalladamente el problema.