Seul Sur Mars - Bande annonce [Officielle] VF HD

Pas trop de rapport avec les bases de données, mais au moment où la NASA confirme avoir trouvé de l'eau sur Mars, Ridley Scott - un de mes réal préférés - nous offre les premières image de son dernier long métrage

Mémo PostGreSQL-PostGis

 

Mémo des principales commandes PostgreSQL

 

 

Créer un utilisateur PostgreSQL

1- Création de l'utilisateur + attribution mdp

CREATE USER mon_utilisateur WITH ENCRYPTED PASSWORD 'UnMotDePasseQuiDéchire';

2- Autoriser l'user à se connecter à une base spécifique (existante)

GRANT CONNECT ON DATABASE LaBase TO mon_utilisateur;

3- Droits génériques : accès au schéma public

REVOKE ALL ON SCHEMA public FROM mon_utilisateur;

GRANT USAGE ON SCHEMA public TO mon_utilisateur;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mon_utilisateur;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO mon_utilisateur;
...

4- Ajuster les droits spécifiques d'un utilisateur

REVOKE ALL ON ALL TABLES IN SCHEMA mon_schéma FROM mon_utilisateur ;

GRANT SELECT ON ALL TABLES IN SCHEMA mon_schéma TO mon_utilisateur ;

En préparation :

Créer une base de données PostGresql

PostGreSQL/PostGIS Broken Package - liblwgeom-2.1.7

Retour d’expérience sur un problème de mise à jour PostGreSQL-9.3/PostGIS-2.1 sur debian.

Si vous êtes confronté à un problème avec la librairie liblwgeom-2.1.7 lors de la mise à jour de PostGreSQL(9.3)PostGIS(2.1) depuis le dépôt officiel, voici une solution rapide et efficace.


Attention, cette méthode impose l’arrêt de votre serveur de base de données.

Lors de la mise à jour de PostGreSQL (9.3) et PostGIS (2.1), c'est à dire des paquets :

liblwgeom-2.1.8 postgis postgis-doc postgresql-9.3-postgis-2.1 postgresql-9.3-postgis-scripts

vous pouvez être confronté à l'erreur suivante :

/var/cache/apt/archives/liblwgeom-2.1.8_2.1.8+dfsg-1.pgdg14.04+1_amd64.deb:
  trying to overwrite '/usr/lib/liblwgeom-2.1.8.so', which is also in
  package liblwgeom-2.1.7 2.1.8+dfsg-1~95.git18216c0.pgdg14.04+1

La librairie liblwgeom-2.1.8 ne peut être installée car la version précédente(2.1.7)ne peut être désinstallée.

Tenter de la désinstaller, n'est pas la meilleur solution à cause des dépendances :

# apt-get remove liblwgeom-2.1.7

Par contre, voici ce qui fonctionne :

# Arrêt du serveur 

service postgresql stop

#Suppression du paquet incriminé, sans prendre en compte des dépendances

dpkg -r liblwgeom-2.1.7

# Correction et poursuite de l'installation précédente

# Fix Broken Package 

apt-get -f install

# Restart du serveur 

service postgresql start

Tout est rentré dans l'ordre !

Origine de la solution : http://askubuntu.com/questions/675347/postgis-broken-package-unmet-dependencies-liblwgeom-2-1-8

Photos

La photo est une passion de longue date.

Faute de temps et de matériel adéquat, j'ai dû patienter quelques années avant de pouvoir vraiment m'adonner à cette passion.

Actuellement, je m’intéresse à de nombreux domaines : photo nature et sportive, même si les domaines du portrait ou le travail en mini studio me font de l’œil.



Retrouver mes différentes galeries sur mon blog dédié http://haptomai.org/ ou sur DeviantArt.

Optimiser les temps de réponse de MySQL - le DNS

Accélérer le temps de réponse de MySQL en désactivant la résolution DNS

Pour traiter des quantités importantes de données (quelques millions de lignes), j'utilise Talend Open Studio for Data Integration.
Toutes mes bases de données MySQL sont hébergées sur une VM (VirtualBox / Debian) en local.

Or, j'ai un petit problème de résolution de nom lié aux règles de sécurité drastiques, ce qui fait que MySQL patauge un peu quand je l’interroge depuis ma machine, que ce soit avec Talend ou autre chose (MySQL WorkBench...) car il veut absolument résoudre mon IP :(

Donc pour contourner ce petit 'problème', il suffit  de désactiver la résolution DNS dans MySQL

Pour cela, ajoutez un ligne dans le fichier de configuration de MySQL (my.cnf) avec l'option suivante :

skip-name-resolve

et redémarrez le serveur MySQL

Et là ! ca marche mieux !

La doc : http://dev.mysql.com/doc/refman/5.1/fr/dns.html

Piwik error after update from 1.7.1 to 1.8.2

Erreur après la mise à jour de piwik depuis la version 1.7.1 vers 1.8.2

Une petite erreur rencontrée lors de la mise à jour automatique de piwik après la mise à jour de la base de données :

SQLSTATE[42000]: Syntax error or access violation: 1044 Access denied for user 'piwik'@'localhost' to database 'piwik'
 Go to Piwik
 Login
 Backtrace:

 #0 /var/www/piwik-1.5.1/core/PluginsFunctions/Sql.php(51): Zend_Db_Adapter_Pdo_Abstract->exec('LOCK TABLES pwk...')
 #1 /var/www/piwik-1.5.1/core/PluginsFunctions/Sql.php(205): Piwik_Sql::exec('LOCK TABLES pwk...')
 #2 /var/www/piwik-1.5.1/core/PluginsFunctions/Sql.php(359): Piwik_Sql::lockTables('pwk_archive_num...', 'pwk_archive_num...')
 #3 /var/www/piwik-1.5.1/core/ArchiveProcessing.php(688): Piwik_LockTables('pwk_archive_num...', 'pwk_archive_num...')
 #4 /var/www/piwik-1.5.1/core/ArchiveProcessing.php(533): Piwik_ArchiveProcessing->loadNextIdarchive()
 #5 /var/www/piwik-1.5.1/core/ArchiveProcessing.php(472): Piwik_ArchiveProcessing->initCompute()
 #6 /var/www/piwik-1.5.1/core/Archive/Single.php(226): Piwik_ArchiveProcessing->launchArchiving()
 #7 /var/www/piwik-1.5.1/core/Archive/Array/IndexedBySite.php(192): Piwik_Archive_Single->prepareArchive()
 #8 /var/www/piwik-1.5.1/core/Archive/Array/IndexedBySite.php(131): Piwik_Archive_Array_IndexedBySite->getArchiveIdsAfterLaunching(Array)
 #9 /var/www/piwik-1.5.1/core/Archive/Array/IndexedBySite.php(108): Piwik_Archive_Array_IndexedBySite->loadValuesFromDB(Array)
 #10 /var/www/piwik-1.5.1/core/Archive/Array/IndexedBySite.php(73): Piwik_Archive_Array_IndexedBySite->getValues(Array)
 #11 /var/www/piwik-1.5.1/plugins/MultiSites/API.php(120): Piwik_Archive_Array_IndexedBySite->getDataTableFromNumeric(Array)
 #12 /var/www/piwik-1.5.1/plugins/MultiSites/Controller.php(65): Piwik_MultiSites_API->getAll('day', '2012-06-06', false)
 #13 /var/www/piwik-1.5.1/plugins/MultiSites/Controller.php(37): Piwik_MultiSites_Controller->getSitesInfo(Object(Piwik_View))
 #14 [internal function]: Piwik_MultiSites_Controller->index()
 #15 /var/www/piwik-1.5.1/core/FrontController.php(138): call_user_func_array(Array, Array)
 #16 /var/www/piwik-1.5.1/index.php(53): Piwik_FrontController->dispatch()


La ligne #0 du log indique que l'utilisateur MySQL 'piwik' n'a pas le droit de poser de verrous (privilège '__LOCK TABLES__' ) sur les tables de la base 'piwik'.

Ce qui est normal puisque je ne lui ai pas donné ce droit ;)

Donc, en plus de privilèges existants, à savoir :
* SELECT
* INSERT
* UPDATE
* DELETE
* CREATE
* DROP
* INDEX
* ALTER
* CREATE VIEW
* SHOW VIEW

Il faut ajouter le privilège d'administration  LOCK TABLES  :

REVOKE ALL PRIVILEGES ON `piwik`.* FROM 'piwik'@'localhost';
 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES, CREATE VIEW, SHOW VIEW
ON `piwik`.* TO 'piwik'@'localhost';
 
Et on oublie pas de recharger les privilèges, ca ne coute rien !
FLUSH PRIVILEGES ;
 
Et c'est reparti !

En résumé, il s'agit plus d'un problème de droits MySQL (un peu trop stricts) que d'un bug de Piwik. D’ailleurs, la FAQ de Piwik est claire sur ce point :

The Mysql USER should have the permission to SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, LOCK.

Have fun !

Initialiser une base PostgreSQL/PostGIS

 

 

 

 

 

Prérequis

• Une instance PostGreSQL fonctionnelle
• Le cartouche PostGIS installé

Préparation de la base

su postgres
createdb mabase
createlang plpgsql mabase
psql -d mabase -f /path/to/postgresql/version/share/contrib/postgis.sql
psql -d mabase -f /path/to/postgresql/version/share/contrib/spatial_ref_sys.sql

Création des tables

psql mabase
CREATE TABLE test (id serial PRIMARY KEY,genre text);

Ajout de la colonne géométrique à la table - AddGeometryColumn()

Pour l'instant notre table est vide, nous allons lui ajouter une troisième colonne où seront stockées nos données géométriques.

Nous aurons recours pour cela à la fonction AddGeometryColumn() de PostGIS dont la synthaxe générale est :

AddGeometryColumn( Table, 
                    Colonne_Geometrique, 
                    SRID, 
                    Type_Geometrie, 
                    Dimension);

où

• Table est le nom de la table à laquelle doit être ajoutée la colonne géométrique;
• Colonne_Geometrique est le nom de la colonne géométrique;
• Type_Geometrie est le le type de géométrie possible:
• SRID est l'identifiant spatial de projection selon le système de projection choisi.
  A titre d'exemple pour le Lambert II Carto Etendu, srid=27852;
• Dimension est la dimension des objets géométriques 2D ou 3D ou 4D;

Dans notre cas, nous saisirons :

SELECT AddGeometryColumn( 'test', 'geom', -1, 'GEOMETRY', 2 );

Avec cette requête, nous avons ajouté la Colonne géométrique geom à la Table 'test'.

Comme nous n'utilisons ici aucun système de projection référencé, nous restons donc dans le plan 2D orthonormal par défaut, nous précisons juste SRID=-1.

Le type de données géométriques (Type_Geometrie) que nous souhaitons enregistrer peut-être de n'importe quel type. Nous préciserons donc par défaut GEOMETRY.
Enfin, nous sommes en 2 Dimensions.

Note
Il aurait été tout à fait possible de créer la table test en faisant directement

CREATE TABLE test (id serial PRIMARY KEY,genre TEXT,geom GEOMETRY);

Mais il y aurait alors eu un perte concernant les méta-données sur les objets géométriques concernant le type, le srid, la dimension.
Il est donc préférable d'avoir recours à la fonction AddGeometryColumn() pour pouvoir tirer profit de ces métadonnées.