[Jde-dev] bug en recordingserver
Roberto Calvo
rocapal en libresoft.es
Lun Abr 26 11:38:21 CEST 2010
mmm no podemos usar el PID como ID, porque pueden existir varios
RECORDER en diferentes máquinas y podrÃa pasar que hubiera 2 grabaciones
con el mismo PID.
Después de leer tus correos y comentar una posible solución con Jose
MarÃa, hemos llegado a esta conclusión, a ver que te parece. En el
RecorderConfig sólo guardamos un campo id, y depende de quienes hablen,
tiene una semántico u otra.
-> Entre el Recorder y RecordingManager, id = PID. Únicamente se usa
para empezar y parar la grabación.
-> Entre el RecordingManager y los demás componentes, id = id_BBDD.
-> El RecordingManager es el encargado de hacer la transformación de
id_BBDD a PID para poder parar las grabaciones (esos datos están en la
BBDD).
¿Qué te parece? Estoy cambiando algo de código para ver si no se nos ha
pasado nada en esta solución, pero parece la que más desacopla y
encapsula el tema del PID, que es exclusivamente lógica del Recorder.
un saludo!
El lun, 26-04-2010 a las 10:50 +0200, Sara Marugan escribió:
> Finalmente creo que la mejor opción es dejar sólo un id en RecordConfig,
> que se corresponda con el pid. El id de la BBDD sólo se necesita al
> insertar un nuevo evento sobre la grabación.
>
> Ahora mismo como lo tengo es que antes de hacer la insercción del
> evento, consulta el id de la BBDD de la grabación sobre la que quiere
> guardar el evento. Lo único que no me acaba de gustar es que tras la
> consulta hay que volver a conectar con la BBDD para que funcione la
> insercción.
>
> Qué os parece esta solución?lo demás se deja tal y como estaba.
>
>
>
> Sara Marugan wrote:
> > Pensándolo he llegado a la conclusión de que se necesitan almacenar
> > ambos ids. El id de la base de datos lo necesitan tanto la aplicación
> > que guarda eventos como la que los quiere consultar después. Y el id que
> > viene del pid lo necesita recorder para matar el proceso de grabación.
> >
> > Ahora mismo como está (sin el cambio) las aplicaciones sólo pueden
> > acceder al id del pid, que es lo que se almacena.
> >
> > Asà que todo apunta a que hay que introducir el campo recoding_id en la
> > configuracion de una grabación.
> >
> >
> >
> > Roberto Calvo wrote:
> >
> >> Sobre los eventos aún no he trabajado con la ultima versión. Pero te
> >> comento unas cosas sobre los ids:
> >>
> >> * El id_rec es el pid del proceso que realiza la grabación, sólo tiene
> >> sentido usarlo cuando la grabación está en curso (para detener el
> >> proceso).
> >> * El id es el identificador único de grabación, que se utiliza para
> >> todo lo demás en grabaciones.
> >>
> >> El código que me pegas, es justo el primer caso, se está lanzando la
> >> grabación, recoge el pid de proceso. En ese mismo momento el recorder no
> >> sabe nada de ID's de base de datos, eso lo sabe el recordingManager.
> >>
> >> Según lo que comentas, necesitamos tener en el RecorderConfig dos
> >> atributos, uno que sea el id normal, y otro el id_rec ¿Con eso se
> >> solucionarÃa el problema, verdad?
> >>
> >> Además, fÃjate que cuando haces un getRecordings, el id si introduce el
> >> correcto, el id único de la BBDD. Si te parece cuéntame un poco más el
> >> problema que tienes y el contexto y vemos como solucionarlo, aunque lo
> >> que he puesto en el párrafo anterior tiene sentido que lo hagamos.
> >>
> >> Mirando el código, creo que el problema pueda estar en que utilizas el
> >> id que devuelve el RecorderConfig al empezar una grabación, para
> >> establecer los eventos de esa grabación ¿es asÃ? Si es asÃ, creo que la
> >> solución pasa por tener un solo campo id en el RecorderConfig, y que sea
> >> el propio recordingManager quien se capaz de obtener el PID, que desde
> >> luego tiene mucho más sentido.
> >>
> >> ConfÃrmame esto último que te comento, y lo cambiamos.
> >>
> >> Gracias por el reporte!
> >> un saludo!
> >>
> >> El jue, 22-04-2010 a las 13:21 +0200, Sara Marugan escribió:
> >>
> >>
> >>> Hola,
> >>>
> >>> haciendo pruebas con recordingserver me daba error al intentar guardar
> >>> un evento sobre una grabación previamente guardada. Concretamente es que
> >>> no coincidÃa el campo recording_id del evento con el id de la grabación.
> >>> Las grabaciones tienen un id y un recording_id. La foreing key de los
> >>> eventos necesita apuntar al id de una grabación, no al recording_id, que
> >>> es como está ahora.
> >>>
> >>> Pongo aquà el snip de código de recordingserver.cpp (lÃnea 78):
> >>>
> >>> // Read the PID
> >>> read (descPipe[0], &pid_rec, sizeof(int));
> >>> //printf("#### rid from insert %d\n",rid);
> >>> recConfig->id = pid_rec;
> >>>
> >>> // Log recording
> >>> int rid=recLog->startRecording(recConfig);
> >>>
> >>> //return pid_rec;
> >>> return rid;
> >>>
> >>> Cambiando esto funciona bien. Creo el ticket y subo el parche?
> >>>
> >>> Un saludo.
> >>>
> >>> Sara.
> >>> _______________________________________________
> >>> Jde-developers mailing list
> >>> Jde-developers en gsyc.es
> >>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Jde-developers mailing list
> > Jde-developers en gsyc.es
> > http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
--
Roberto Calvo Palomino | Libre Software Engineering Lab (GSyC)
Tel: (+34) 91 488 85 23 | Universidad Rey Juan Carlos
rocapal en libresoft.es | Edif. Departamental II - Despacho 116
http://libresoft.es/ | c/Tulipán s/n 28933 Móstoles (Madrid)
GPG-KEY: http://gsyc.es/~rocapal/rocapal.gpg
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre : no disponible
Tipo : application/pgp-signature
Tamaño : 198 bytes
Descripción: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
digitalmente
Url : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100426/d427fcf5/attachment.pgp
More information about the Jde-developers
mailing list