[Jde-dev] bug en recordingserver

[Sara Marugan]

Esa opción también la pensé pero la descarté porque vi que las 
aplicaciones debían guardar el pid para llamar al stop del 
recordingmanager. Sin embargo si se hace la conversión en el 
recordingmanager todo queda más encapsulado. Además lo de posibles ids 
duplicados no se puede permitir claro.

Me parece bien esta solución!


Roberto Calvo wrote:
> 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
>>     
>
>