Migrar tweets a BlueSky

•  Exportar datos de Twitter (X)

Una vez solicitado se recibirá un email (menos de 24 horas) avisando que los datos están listos.

• Descargar repositorio https://github.com/marcomaroni-github/twitter-to-bluesk
• Seguir los pasos para ejecutar el programa que vienen en la página anterior. En resumen son:

1. Tener instalado NODE
2. Generar una contraseña en Bluesky para utilizarla con el programa de migración. Ir a configuración - Privacidad y Seguridad - Contraseñas de App - Añadir una nueva.
3. Una ver copiado el repositorio instalar los paquetes desde la terminal: npm install
4. Ejecutar el programa. Ejemplo: node app.js --archive-folder /Users/nombreusuario/carpeta-importada-twitter --bluesky-username jp-romero.bsky.social --bluesky-password qwer-asdf-zxccv-1234 --twitter-handles _juanpa --ignore-video-errors

Ni posible ni deseable tener el software a su última versión.

Cuando se desarrolla un programa para el que utilizamos librerías (paquetes, plugins), otro software a fin de construir nuestro software. Al existir dependencias entre programas tenemos que estar pendientes de las actualizaciones de todas las partes de nuestro software.

Si hacemos una analogía con construir un edificio y construir software diciendo que los ladrillos, columnas son piezas de software que no necesariamente desarrollamos nosotros sino de las que nos servimos como apoyo, la diferencia a destacar es que en el software los elementos no son estáticos, el software está en constante cambio y tenemos que cambiar constantemente los ladrillos de nuestro software. Así se escoja piezas de software altamente utilizadas con una larga duración en el mercado pueden dejar de utilizarse y ser necesario un cambio.

En el siglo pasado adquiríamos un producto cerrado. Ahora se tiende a servicios que incorporan constantemente cambios.

¿Por qué no es posible tener la última versión?

La última versión no es compatible. 

Como estamos integrando varios programas hay dependencias. Cuando se actualiza el software no solo es por mejorar la seguridad, puede darse un cambio de estructura, actualización del lenguaje, funcionalidad, etc. Algunos cambios hace que se produzca un cambio importante que hace que la nueva versión no sea compatible con otras versiones. 

Por ejemplo, nuestro software puede no ser compatible con versiones 1.x.x y 2.x.x pero si con la 3.x.x, 4.x.x pero cuando sale la 5.x.x no es compatible porque hay cambio en el lenguaje así que para poder actualizar toca realizar cambios en nuestro software.

Se suele utilizar una forma de nombrado o versionado para indicar cambios menores y por lo tanto si se usa un software 1.1.1 y se pasa a utilizar el 1.2.0 no debe ser problemático pues es un pequeño cambio. Un cambio más grande que puede crear la necesidad de cambio en nuestro código para poder adaptarlo puede ser pasar de un 1.4.10 a 2.0.0. Sin embargo, si se introduce un fallo da igual si es un cambio pequeño 1.1.1 a 1.1.2.

¿Por qué no es deseable tener la última versión?

La última versión tiene fallos. 

Sí, la recomendación es que nuestro software esté con las últimas actualizaciones por seguridad. ¿Acaso no pueden introducir algún problema en la última versión? Sí, aunque se haga todo lo posible por evitar esto puede pasar. Así que la solución suele ser liberar una nueva versión que soluciona el fallo pero hasta que pasa eso, que pueden ser horas, meses o nunca, se opta por volver a una versión anterior.

Como caso particular una vez trabajaba con un plugin para un software costoso, ampliamente utilizado y tanto el programa principal como el plugin eran desarrollados por la misma empresa. Desde soporte solo se ofreció realizar el trabajo del plugin por lo que debía enviar mis archivos a ellos. Para mí no era una solución ya que quería tener el control de usar varias veces el plugin. Además, como suele ser lo usual el fabricante tiene las versiones anteriores disponibles, pues este fabricante no las facilitaba. Y el fallo mío fue tampoco tener las versiones anteriores que funcionaron. Tardaron en sacar la nueva versión sin el fallo casi un año.

Realizar actualizaciones puede ser fácil pero no rápido

Debido a la dependencia que existe entre las distintas piezas de software que integran nuestro programa cuando se actualiza una parte puede afectar a varias y así no funcionar. Entonces, toca buscar la versión más actual posible sin fallos que sea compatible con el resto de programas.

Cuando no es compatible puede ser por un cambio mayor el cual tiene como efecto que debamos hacer cambios en nuestro código para poder hacerlo compatible. ¿Y por qué vamos a querer esto? Porque queremos avanzar con el resto de componentes que ayudan a nuestro software porque las versiones antiguas no se les suele seguir dando soporte, ni mejoras, ni nada.

2022-09-28

Activar/desactivar todas las constraints de todas las tablas. Oracle.

«Si lo que buscas es cómo activar, desactivar u obligar UNA constraint; mira la entrada: Modificar el estado de una constraint»

Para activar o desactivar todas las constraints de las tablas de un esquema he creado dos procedimientos.

El procedimiento dis_all_cons se encargará de desactivar todas las constraints de las tablas de un usuario determinado, por defecto el usuario que invoca el procedimiento.

El usuario que ejecuta el procedimiento debe de ser capaz de tener acceso a las tablas del esquema en cuestión y poder realizar un ALTER sobre ellas.

El procedimiento intentará desactivar las constraints en cascada, así que si existen tablas en otro esquema que hacen referencia (foreign key) a una del esquema del que queremos desactivarlas (primary key) también las desactivará, y si no tenemos permisos fallará. El procedimiento que las activa ena_all_cons no tiene en cuenta a estas constraints que se encuentran en otros esquemas. Espero hacerlo en algún momento, ya que no sé cómo hacer una activación en cascada fácilmente.

Podemos consultar previamente la información de las constraints de las tablas del esquema que queremos modificar y ver su estado entre otras cosas.
Ejemplo utilizando el esquema SCOTT

select  table_name,constraint_name,constraint_type,status,r_constraint_name
from    all_constraints
where owner='SCOTT';

create or replace procedure dis_all_cons
(    p_owner    varchar2    default USER
)

--Uso: dis_all_cons[('esquema')];
--dis_all_cons;           --desactiva las constraints del esquema de quien ejecuta
--dis_all_cons('HR');   --desactiva las constraints del esquema HR

--el procedimiento se ejecutará con los permisos de quien lo invoca

authid current_user

as

begin

    --obtenemos nombre de la tabla y nombre de la restricción

    --pertenecientes al usuario especificado

    --que no estan desactivadas

    --primary key que no sean de tablas organizadas por indice

    --o cualquier otra constraint q sea del tipo C ó U ó R

    for reg in (select    table_name,constraint_name
                   from       all_constraints
                   where     owner=p_owner
                       and     status<>'DISABLED'
                       and (    (constraint_type in ('P')
                                    and table_name not in
                                               (select table_name
                                                from   all_tables
                                                where owner=p_owner
                                                    and iot_type is not null
                                               )
                                    )
                                or    constraint_type in ('C','U','R')
                               )
                   )
    loop
        execute immediate 'alter table '||p_owner||'.'||reg.table_name||' DISABLE constraint '||reg.constraint_name||' cascade';
    end loop;
end dis_all_cons;
/
------------------------------------------------------------------------------------------

create or replace procedure ena_all_cons
(   
    p_owner    varchar2    default USER
)

--Uso: ena_all_cons[('esquema')];

--ena_all_cons;           --activa las constraints del esquema de quien ejecuta

--ena_all_cons('HR');   --activa las constraints del esquema HR

authid current_user

as

begin

    --obtenemos nombre de la tabla y nombre de la restricción

    --pertenecientes al usuario especificado

    --que no estan activadas

    --primary key que no sean de tablas organizadas por indice

    --primero se activan todas las primary key

    for reg in (select     table_name,constraint_name
                   from        all_constraints
                   where     owner=p_owner
                       and status<>'ENABLED'
                       and constraint_type in ('P')
                       and table_name not in
                                                    (select table_name
                                                     from   all_tables
                                                     where iot_type is not null
                                                    )
                   )
    loop
        execute immediate 'alter table '||p_owner||'.'||reg.table_name||' ENABLE constraint '||reg.constraint_name;
    end loop;
    --se activan el resto de constraints

    --de tipo C,U y R

    for reg in (select   table_name,constraint_name
                    from     all_constraints
                    where   owner=p_owner
                        and  status<>'ENABLED'
                        and  constraint_type in ('C','U','R')
                )
    loop
        execute immediate 'alter table '||p_owner||'.'||reg.table_name||' ENABLE constraint '||reg.constraint_name;
    end loop;
end ena_all_cons;
/

El uso de estos procedimientos queda bajo responsabilidad de quien los utilice.

Activar/desactivar todos los disparadores de todas las tablas. Oracle.

Si solo se quiere desactivar un disparador o todos los de una sola tabla, ver el post «Activar/desactivar disparadores»

Para poder desactivar o activar todos los disparadores —triggers— de todas las tablas de un esquema determinado en Oracle, creamos el siguiente procedimiento que realizará la tarea. (distinto es, triggers de los cuales se es propietario)

create or replace procedure ena_dis_all_tri
(    p_opcion    varchar2    default 'DISABLE'
,    p_owner     varchar2    default USER
)
/*
-- procedimiento que activa o desactiva todos los disparadores de todas las tablas del esquema especificado
-- recibe dos parametros opcionalmente:
-- p_opcion (enable, disable).
-- p_owner esquema/usuario al que le desactivamos/activamos los triggers de sus tablas.
-- valores por defecto de los parametros:
-- p_opcion=disable p_owner=user
-- Uso: ena_dis_all_tri[([p_opcion=>'p_opcion'][,p_usuario=>'p_usuario'])]
-- Ejemplos:
-- ena_dis_all_tri; --desactiva los triggers del usuario que ejecuta
-- ena_dis_all_tri(p_opcion=>'enable'); --activa los triggers del usuario que ejecuta
-- ena_dis_all_tri(p_usuario=>'hr'); --desactiva los triggers del usuario hr
-- ena_dis_all_tri(p_opcion=>'enable',p_usuario=>'hr'); --activa los triggers del usuario hr
*/ 
as
    --variable auxiliar
    v_aux        number;
    --cursor que nos dará el nombre de las tablas

    --que hay que activar/desactivar todos los triggers
     cursor cur is
        select    table_name
        from     all_triggers
        where   table_owner=upper(p_owner)
            and status<>p_opcion||'D';
begin

    --------------esta partes es opcional, solo sirve para realizar unas comprobaciones

    --comprobamos de que no se ha introducido mal el nombre de usuario

    select  count(username)
     into     v_aux
     from    all_users
     where username=upper(p_owner);
    if v_aux=0 then
        raise_application_error(-20000,'El usuario "'||p_owner||'" no existe.');
    end if;

    --comprobamos de que no se ha introducido mal la opcion

    if upper(p_opcion) not in ('ENABLE','DISABLE') then
        raise_application_error(-20001,'Opción "'||p_opcion||'" no válida. Usar: "ENABLE" o "DISABLE"');
    end if;

    --------------fin parte opcional

    --ejecutamos la tarea

    for reg in cur loop
        execute immediate 'alter table '||p_owner||'.'||reg.table_name
                                      ||' '||p_opcion||' all triggers';
    end loop;
end ena_dis_all_tri;
/

Se ha realizado en una base de datos Oracle 10.2.0.1

El procedimiento se ejecutará con los permisos del usuario que cree el procedimiento. Debe tener privilegio CREATE ANY TRIGGER para poder visualizar los triggers en la vista ALL_TRIGGERS o tener acceso a las tablas. Además, permiso ALTER sobre las tablas y sobre los triggers, éste último porque pueden existir triggers asociados a las tablas del esquema creados por otro usuario.

grant alter any trigger,
          alter any table,
          create any trigger to usuario;

Comprobar la información con la siguiente SELECT:

select  owner,trigger_name,table_name,status
from    all_triggers
where  table_owner='USUARIO';

El uso del procedimiento queda bajo responsabilidad de quien lo utilice.