[Jde-dev] bug en recordingserver
Sara Marugan
smarugan en gsyc.es
Lun Abr 26 10:50:53 CEST 2010
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
>
More information about the Jde-developers
mailing list