MySQL Workbench – Problematica su ProcessList

https://bugs.mysql.com/bug.php?id=102465 

 

[3 Feb 16:10] Adam Latchem 

Using MySQL Workbench 8.0.28 I was able to fix this by changing line modules\wb_admin_connections.py:346

from: 

                             (“DB“, mforms.StringColumnType, “DB”, 100), 

 to 

                             (“db“, mforms.StringColumnType, “DB”, 100), 

 0 

The proposed solution “[3 Feb 16:10] Adam Latchem” worked for me, in the context of MySQL Workbench connecting to a MariaDB database. The fix (for definiteness) is to edit the file C:\Program Files\MySQL\MySQL Workbench 8.0 CE\modules\wb_admin_connections.py at line 346, to change it from 

(“DB”, mforms.StringColumnType, “DB”, 100), 

to 

(“db”, mforms.StringColumnType, “DB”, 100), 

(note change of case in first argument). 

 

 

Notifiche Push con Google Cloud Messaging

Molte app Android possono avere la necessità di usufruire delle cosiddette Push Notifications (o notifiche Push in italiano). Si tratta di una tecnologia che consente al destinatario di una notifica, di riceverla senza che esso debba eseguire un’esplicita operazione di scaricamento delle notifiche disponibile (secondo il più tradizionale schema pull).

L’implementazione di un meccanismo di notifiche push, e l’integrazione di esso all’interno di un’app Android, sarebbero operazioni complesse e proibitive se non esistesse una piattaforma dedicata come Google Cloud Messaging.

Perchè usare Push Notifications?

Tipicamente, nelle applicazioni di rete basate sul protocollo HTTP, l’iniziatore del dialogo tra il client ed il server è, solitamente, il client.

Immaginiamo una situazione applicativa in cui un server fornisca dati (news tematiche, articoli tecnici o altro ancora) ed un’app Android sia progettata per usufruire del servizio. Supponiamo anche che i nuovi dati non vengano pubblicati con regolarità ma con tempistiche del tutto imprevedibili, più volte al giorno o solo poche volte in un mese.

L’ottimizzazione di un’app del genere ruota attorno alla modalità scelta per verificare la disponibilità o meno di contenuti aggiornati. Come prima ipotesi, potremmo pensare ad un accesso periodico al server, implementato mediante AlertManager. Una tecnica di questo genere, detta polling, ha come unico vantaggio la semplicità concettuale e realizzativa, ma presenta anche alcuni svantaggi. In primis, il client invia molte richieste, la maggior parte delle quali non forniscono nuovi dati prodotti. Immaginiamo, ad esempio, che un client acceda al servizio remoto ogni 30 minuti, e che il server, per un qualche motivo, generi nuovi dati solo una volta nell’arco della giornata in esame. Avremmo fatto 2 accessi all’ora per un’unica fornitura di dati, sprecando traffico di rete ed energia. Un altro svantaggio è che la produzione di nuovi dati dal server non viene comunicata tempestivamente al client. Supponiamo che il nostro client, collegandosi al server ogni 30 minuti, faccia un accesso alle 10:00. Se il server fornisse i dati alle 10:01, essi perverrebbero al client solo con l’accesso delle 10:30, quasi con mezz’ora di ritardo.

Il meccanismo delle Push Notification funziona esattamente in maniera opposta al polling: il server sarà in grado di avvisare il client, in modo asincrono, al momento della disponibilità di nuovi dati.

La gestione di questo meccanismo su Android può essere affidata ad un servizio chiamato Google Cloud Messaging (o GCM), che semplifica di molto l’onere implementativo. Tale piattaforma è facilmente integrabile in Android mediante Google Play Services.

Google Cloud Messaging

Il meccanismo delle notifiche push, come vedremo, consente ad un’applicazione esterna di influenzare il normale flusso di esecuzione delle nostre app.

Per questo motivi, d’ora in avanti parleremo di tre attori principali:

  • l’app Android, intesa nella totalità delle installazioni che di essa sono state fatte nel mondo;
  • l’applicazione esterna, che ha la necessità di inviare notifiche alle app Android interessate;
  • GCM, che svolge il ruolo di mediatore tra i due attori precedentemente elencati.

Essenzialmente, l’applicazione esterna invierà le notifiche alla piattaforma GCM, la quale si occuperà di inoltrarle alle applicazioni destinatarie.

Affinchè tutto questo funzioni è necessario che il dispositivo mobile, alla prima esecuzione dell’app che starà in attesa delle notifiche push, si registri presso GCM e comunichi all’applicazione esterna il codice di registrazione ricevuto.

Pertanto il nostro progetto dovrà trattare tre tipi di token di informazione:

  • il SENDER ID: conservato nell’app Android, verrà inviato in fase di registrazione a GCM;
  • il REGISTRATION ID: un codice che GCM restituirà al client a seguito della registrazione. Il client, a sua volta, lo inoltrerà all’applicazione che invia le notifiche;
  • la SERVER KEY: una chiave di autenticazione che l’applicazione esterna possiede, utilizzata per ogni richiesta di invio di notifiche a GCM.

Vedremo nel seguito che ogni volta che l’applicazione esterna dovrà inviare ad un client una notifica push, essa fornirà a GCM:

  • le informazioni che costituiscono la notifica;
  • la propria SERVER KEY per essere riconosciuto;
  • i REGISTRATION ID dei dispositivi mobili che dovranno ricevere la notifica.

Prerequisiti e preparazione tecnica all’esempio

Prima di passare all’esempio pratico, è bene elencare gli strumenti di cui avremo bisogno, e che abbiamo già visto in precedenza:

  • Google Play Services: il progetto Android deve esserne provvisto, procedendo come spiegato in una lezione precedente;
  • progetto Google: dovremo avere a disposizione un progetto Google creato tramite Google Developers Console, come illustrato in una lezione precedente. Il Project Number assegnato al progetto costituirà il SENDER ID che l’app Android userà in fase di registrazione;
  • configurazione del progetto Google: per prima cosa si dovranno attivare le API relative a GCM nella sezione APIs & Auth, denominate Google Cloud Messaging for Android. Successivamente, nella sezione Credentials, si dovrà creare una Public Access Key. Anche questo aspetto è stato già illustrato in una lezione precedente.

La differenza rispetto a quanto visto negli altri servizi Google è che questa volta non avremo bisogno di una chiave di tipo Android key, bensì di una Server key, che verrà usata dall’applicazione esterna per inviare le notifiche. Nella finestra di dialogo che si apre cliccando sul pulsante Create new Key, dovremo selezionare Server key, cerchiato in rosso nella figura seguente:

L’esempio

L’esempio proposto nelle lezioni seguenti mostrerà come utilizzare le notifiche push. Essp è composto da:

  • un’app Android che si registra presso GCM e riceve notifiche push;
  • una pagina PHP, rappresentante l’applicazione esterna, che deve inviare notifiche al client. Tale ruolo può essere interpretato con qualunque tecnologia basata sul protocollo HTTP. La leggibilità di PHP dovrebbe consentire, anche a chi non ha mai usato questo linguaggio, una facile interpretazione del codice.

Il meccanismo dell’esempio segue lo schema rappresentato in figura.

Osserviamolo soffermandoci sul significato delle frecce numerate:

  1. all’apertura dell’applicazione, il client invia il SENDER ID a GCM, che consiste nel Project Number del progetto Google;
  2. GCM, a registrazione avvenuta con successo, invia all’app il REGISTRATION ID, un codice alfanumerico piuttosto lungo;
  3. l’app riceve il REGISTRATION ID e lo invia allo script remoto in PHP;
  4. lo script PHP, appena ricevuto il REGISTRATION ID, potrà (in qualsiasi momento, in maniera asincrona) chiedere a GCM di inviare una notifica al client. Le informazioni che gli fornisce sono costutuite dal REGISTRATION ID per riconoscere il client, la SERVER KEYper identificare sé stesso ed il messaggio da inviare al client;
  5. GCM invia la notifica push al client. Tale comunicazione verrà intercettata da un BroadcastReceiver che segnalerà l’evento con una notifica all’utente.

vedi anche 

Come utilizzare Firebase Cloud Messaging con Android

 

 

IOS Sierra e VirtualBox

Install macOS 10.12 Sierra Final on VMware on Windows PC (Download Link)
https://youtu.be/m5s5Vrm_Kqk

Install macOS 10.12 Sierra Final on VirtualBox on Windows PC (Download Link)
https://youtu.be/nhl7E9k5wO4

 

 

cd “D:\Program Files\Oracle\VirtualBox\”

VBoxManage.exe modifyvm “macOS 10.12 Sierra” –cpuidset 00000001 000106e5 00100800 0098e3fd bfebfbff

VBoxManage setextradata “macOS 10.12 Sierra” “VBoxInternal/Devices/efi/0/Config/DmiSystemProduct” “iMac11,3”

VBoxManage setextradata “macOS 10.12 Sierra” “VBoxInternal/Devices/efi/0/Config/DmiSystemVersion” “1.0”

VBoxManage setextradata “macOS 10.12 Sierra” “VBoxInternal/Devices/efi/0/Config/DmiBoardProduct” “Iloveapple”

VBoxManage setextradata “macOS 10.12 Sierra” “VBoxInternal/Devices/smc/0/Config/DeviceKey” “ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc”

VBoxManage setextradata “macOS 10.12 Sierra” “VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC” 1

https://blog.udemy.com/xcode-on-windows/

 

Oracle: Procedure

-- including OR REPLACE is more convenient when updating a subprogram
CREATE OR REPLACE PROCEDURE award_bonus (emp_id NUMBER, bonus NUMBER) AS  commission REAL;
comm_missing EXCEPTION;
BEGIN -- executable part starts here
 SELECT commission_pct / 100 INTO commission FROM employees
 WHERE employee_id = emp_id;
 IF commission IS NULL THEN
 RAISE comm_missing;
 ELSE
 UPDATE employees SET salary = salary + bonus*commission 
 WHERE employee_id = emp_id;
 END IF;
EXCEPTION -- exception-handling part starts here
 WHEN comm_missing THEN
 DBMS_OUTPUT.PUT_LINE('This employee does not receive a commission.');
 commission := 0;
 WHEN OTHERS THEN
 NULL; -- for other exceptions do nothing
END award_bonus;

Oracle: merge table

MERGE INTO impiegati dst
USING (
select a.employee_id, a.last_name || ‘ ‘ || first_name as nome, salary, a.department_id
from EMPLOYEES a
where a.department_id in (select department_id from departments)
) src ON (src.employee_id = dst.impiegato_numero)
WHEN NOT MATCHED
THEN INSERT(impiegato_numero,impiegato_nome,stipendio,dipartimento_id)
VALUES(src.employee_id, src.nome, src.salary, src.department_id )
WHEN MATCHED THEN UPDATE SET dst.dipartimento_id = src.employee_id;

Oracle: Read Table

REM set server output to ON to display output from DBMS_OUTPUT
SET SERVEROUTPUT ON

DECLARE
CURSOR Cur1 IS
select * from HR.COUNTRIES;
Rec1 Cur1%rowtype;
BEGIN

FOR someone IN (SELECT * FROM hr.employees WHERE employee_id < 120 )
LOOP
DBMS_OUTPUT.PUT_LINE(‘Nome = ‘ || someone.first_name ||
‘, Cognome = ‘ || someone.last_name);
END LOOP;
open Cur1;
— FOR j IN 1..100 LOOP — Analizza i primi 100 elementi
LOOP
FETCH Cur1 INTO Rec1;
exit when Cur1%notfound;
DBMS_OUTPUT.PUT_LINE(‘Paese:’||Rec1.country_name);

end loop;

close Cur1;
end;

 

Oracle: Exception

ALTER SESSION SET CURRENT_SCHEMA = HR;

 

BEGIN
 EXECUTE IMMEDIATE 'DROP TABLE mytable';
EXCEPTION
 WHEN OTHERS THEN
 IF SQLCODE != -942 THEN
   RAISE;
 END IF;
END;
create table mytable (
num int not null primary key,
nominativo varchar(50));
set serveroutput on
 
insert into mytable values(1,'Tizio Caio');
insert into mytable values(6,'Caio Duilio');
begin
 insert into mytable values(2,'Paolo Rossi');
 insert into mytable values(15,'Nicola Tux');
 insert into mytable values(1,'Nicola Tux');
exception
 when dup_val_on_index then
 dbms_output.put_line('Attenzione oops:' || sqlerrm);
 rollback;
end;

select * from mytable;

commit;

— Divide by zero

DECLARE v_invalid PLS_INTEGER;
BEGIN
v_invalid := 100/0;
EXCEPTION
WHEN ZERO_DIVIDE THEN
DBMS_OUTPUT.PUT_LINE (‘attenzione il risultato è in errore (divide by 0)’);
END;

Oracle: Raise

DECLARE
 v_deptno NUMBER := 500;
 v_name VARCHAR2 (20) := 'Acquisti';
 e_invalid_dept EXCEPTION;
 BEGIN
 UPDATE HR.departments
 SET department_name = v_name
 WHERE department_id = v_deptno;
 IF SQL%NOTFOUND THEN
    RAISE e_invalid_dept;
 END IF;
 ROLLBACK;
 EXCEPTION
 WHEN e_invalid_dept THEN
 
 DBMS_OUTPUT.PUT_LINE ('Department: [' || v_name || '] non trovato');
 DBMS_OUTPUT.PUT_LINE (SQLERRM);
 DBMS_OUTPUT.PUT_LINE (SQLCODE);
 END;

Oracle: Shell Unix – Script Sql PLSql / Argomenti Variabili da Shell Unix a Script Sql (e viceversa)

Shell Unix – Script Sql PLSql / Argomenti Variabili da Shell Unix a Script Sql (e viceversa)

–> Script Testati su Oracle 11g  <–

Metodo 01) Richiamo Script sql da shell Unix:

–>Shell
#!/bin/ksh

sqlplus -S /nolog <<EOF
connect $USER/$PASSWD@$DB

set echo on timing on time on term on;
set serveroutput on;
spool $FILE_TMP;
WHENEVER SQLERROR EXIT 99
@$PIPPO.SQL;
spool off
EXIT
EOF
#–>Get Ritorno da Shell
rit=$?
–>Alternativa..
WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK;
SET DEFINE OFF;
statement sql…
COMMIT;

QUIT;

Metodo 02) Passaggio Argomenti allo script sql e passaggio risultato dello Script sql alla shell Unix:

#!/bin/ksh

sqlplus -s /NOLOG << EOF >> ${LOG_FILE}
SET FEEDBACK ON;
SET TERMOUT ON;
SET SERVEROUTPUT ON;
WHENEVER OSERROR EXIT SQLCODE;
WHENEVER SQLERROR EXIT SQL.SQLCODE;
CONNECT ${USER}/${PWD}@${DB_NAME[INDEX]};

PROMPT FILE IN ESECUZIONE: ${PROC}
@${PROC} ${ArgomentoPerScriptSQL1} ${ArgomentoPerScriptSQL1} ${ArgomentoPerScriptSQL1}
— Gli argomenti nello script SQL andranno gestiti con la &1-&2-&3
PROMPT SCRIPT  ${PROC} Run OK
COMMIT ;
EXIT success;
/
EOF
#–>Get Ritorno da Shell
Ret=${?}
Metodo 03) Passare alla shell un risultato della query
#!/bin/ksh
x=`sqlplus -s U_SIE/SIE@RGSSVIL_RAC.ETLS <<EOF
select DUMMY from dual;
exit
EOF`
echo  RISULTATO $x
Metodo 04)
–File 1 pr3.ksh
#!/bin/ksh
sqlplus -s U_SIE/SIE@RGSSVIL_RAC.ETLS <<EOF
@pr3.sql
EOF
retcode=$?echo “retcode is ${retcode}”

–Opzione 1 File 2 pr3.sql

set heading off
set feed off
set pagesize 0
set head off
set term off
set VERIFY OFF
select count(*) into :ret_val from dual;
exit :ret_val;

–Opzione 2 File 2 pr3.sql
VARIABLE ret_val NUMBER
begin
select count(*) into :ret_val from dual;
end;
/
exit :ret_val;
Metodo 5) Gestire il ritorno di uno script SQL
sqlplus $usr/$pwd@$sid # Output Oracle
@${path_script}/script.sql ${Argomento}
if [ $? != 0 ] then
  msg_txt=”The execution failed. Please investigate.”
  echo ${msg_txt}
fi

Oracle: USER – SCHEMA – Create / Profile/ Get DDL / Roles / Privileges (system e object

   USER – SCHEMA – Create / Profile/ Get DDL / Roles / Privileges (system e object)

–> Script Testati su Oracle 11g  <–

——————-
—  CREATE USER  
——————-
create user pippo     identified by        xxx
default tablespace   users
temporary tablespace temp
quota unlimited on   users
profile              default
account              unlock;
grant connect, resource to pippo;
grant create database link,
create view,
create synonym,
create sequence,
alter session
to pippo;
————–
— Profilo  —
————–

–>Il profilo di default assegnato ad ogni utenza è ‘DEAFAULT’ trovabile in dba_users:

select USERNAME, PROFILE
from dba_users
where username=upper(‘&nome_user’);

— >Per sapere I settaggi di un profile (in questo caso il profile ssegnato perDEFAULT a tutti gli schema)

SELECT RESOURCE_NAME,
LIMIT
FROM DBA_PROFILES
WHERE PROFILE=’DEFAULT’;

— Per modificare il profile:

ALTER PROFILE
DEFAULT
LIMIT
FAILED_LOGIN_ATTEMPTS UNLIMITED
PASSWORD_LIFE_TIME UNLIMITED;
—————
—  GET DDL  
—————
–Dalla funzione dbms_metadata.get_granted_ddl return CLOB
set longchunksize 30000
set long 30000
show long
select dbms_metadata.get_ddl( ‘USER’, ‘XBSESDBO’ ) from dual
UNION ALL
select dbms_metadata.get_granted_ddl( ‘SYSTEM_GRANT’, ‘XBSESDBO’ ) from dual
UNION ALL
select dbms_metadata.get_granted_ddl( ‘OBJECT_GRANT’, ‘XBSESDBO’ ) from dual
UNION ALL
select dbms_metadata.get_granted_ddl( ‘ROLE_GRANT’, ‘XBSESDBO’ ) from dual;
———————————————————– Data Dictionary Roles / Privileges (system e object)
———————————————————
dba_users      –> visualizza gli schema di un database
dba_profiles   –> visualizza I settaggi dei “profile”
dba_sys_privs  –> system privileges granted to users and roles
dba_tab_privs  –> object grants
dba_role_privs –> roles granted to all users and roles in the database
altre..
DBA_COL_PRIVS
————————————–
— Elenco Privilegi sulle Tabelle   —
————————————–
set line 250
set pagesize 400
column GRANTOR format a20
column OWNER format a20
column PRIVILEGE format a25
select count(*)     ,
OWNER       ,
GRANTOR   ,
GRANTEE    ,
PRIVILEGE
from dba_tab_privs
where GRANTEE like ‘%PIPPO%’   –User / Ruolo che riceve la GRANT
  and PRIVILEGE like ‘SELECT%’ –Privilegio Concesso all’Oggetto  — and owner      = ‘USER_PROPRIETERIO_OGGETTO_GRANTATO’  — and TABLE_NAME = ‘NOME_TABELLA_GRANTATA’
  — and GRANTOR    = ‘NOME_UTENTE_CHE_HA_CONCESSO_LA_GRANT’
group by
OWNER,
GRANTOR ,
GRANTEE,
PRIVILEGE
;
—————————–
— Elenco di tutti i Ruoli 
—————————–RUOLI: Non hanno un proprietario, una volta creati (da utenze con I diritti per farlo (‘grant create role to pippo;’) se si ha l’admin option (per default lo ha l’utenza creatrice) possono essere concessi ad alltri utenti.
select *
from dba_roles
order by role
;
—————————————
— Ruoli assegnati agli Utenti/Ruoli 
—————————————
Elenca I Ruoli elargiti a tutti gli utenti/ruoli del database
–>Solo Ruoli Assegnati ad altri Ruoli
select * from DBA_ROLE_PRIVS
where GRANTEE not in (select username from dba_users)
order by GRANTEE
;
—————————————–
— System Privilege assegnati ai Ruoli 
—————————————–
Elenca I System Privileges elargiti agli User/Ruoli.

–>Solo System Privilege assegnati ai Ruoli

select * from DBA_SYS_PRIVS
where GRANTEE not in (select username from dba_users)
–and PRIVILEGE like ‘%EXEC%’
order by GRANTEE
;
———————————–
—  RUOLI ASSEGNATI AGLI SCHEMA  
————————————->Quntità Ruoli (vision generale)
select count(*), GRANTEE, ADMIN_OPTION
from dba_role_privs
where ADMIN_OPTION=’YES’
group by GRANTEE, ADMIN_OPTION
/–>Elenco per Schema
select GRANTED_ROLE, GRANTED_ROLE, DEFAULT_ROLE
from dba_role_privs
where GRANTEE=’&1′
/
———————————————————-
— Users a cui gli è stato concesso il ruolo di CONNECT 
———————————————————-
set linesize 175
column PATH_OF_CONNECT_ROLE_GRANT format a40
select * from DBA_CONNECT_ROLE_GRANTEES
order by GRANTEE
;
—————————————————————-
—  Visualizza Solo per i Ruoli a cui gli User hanno accesso  
—————————————————————-
Se l’interrogazione viene fatta da un utenza che ha i diritti di lettura sulla Data Dictionary, allora potrà visualizzarli tutti, altrimenti vedrà solo quelli di sua competenza.
ROLE_ROLE_PRIVS –> roles elargiti ad altri roles
ROLE_SYS_PRIVS  –> system privileges grantate ai roles
ROLE_TAB_PRIVS  –> table privileges grantate ai roles

——————-
— DEFAULT ROLE  —
——————-

DEFAULT ROLE ALL — Solo I ruoli che sono stati elargiti all’utente sono abilitati per default quando l’utente stesso si college.

ALTER USER SCOTT DEFAULT ROLE ALL;

SQL> conn newuser/newuser
Connected.
SQL> select * from session_roles;ROLE
——————————
CONNECT
NEW_USERSQL> conn / as sysdba
Connected.
SQL> alter user newuser default role connect;

User altered.

SQL> conn newuser/newuser
Connected.
SQL> select * from session_roles;

ROLE
——————————
CONNECT