Commentaires sur : Catalogue Lightroom en réseau : ce que dit le site SQLite

Par : Benoît

Benoît — Sat, 27 Apr 2013 14:37:36 +0000

J’adore SQLite parce que justement, entre autre il ne peut pas être utilisé en réseau donc, il est plus facile de déployer une base de données SQLite que les autres, un simple glisser-déplacer est suffisant.

Dans les autres cas, il faut définir un serveur, un administrateur de base de données, une stratégie de sauvegarde etc… C’est plus compliqué…

Mais si le développement a été fait dans les règles de l’art, il est assez simple de changer de base de données. Ce sont des bases de données SQL, le language SQL est normé et très bien respecté par SQLite.

Ce que je veux dire est que le fait que LR utilise SQLite n’est pas un frein pour changer de base de donnée mais plutôt comment l’architecture du logiciel est articulé.

Il est évident si les appels à la bd ne sont pas encapsulés, le portage de LR vers une autre bd deviendra vite problématique.

Par : Fabrice Bacchella

Fabrice Bacchella — Wed, 10 Apr 2013 22:03:32 +0000

Une base de données (surtout les bases de données de type SQL) ont à gérer deux besoins contradictoires : être réactives, performantes d’un coté et garantir que les données sur disques sont dans un état cohérent, que rien ne sera perdu en cas de panne. Le premier demande de ne jamais accéder au disque, le seconde de toujours y accéder. Il existe de nombreux mécanismes subtils pour parvenir à réconcilier ces deux frères ennemis, mais il demande un nombre réduit d’intermédiaire entre l’application et les plateaux du disque. Les protocoles de partage de fichier sont trop complexes trop peu fiable pour ça : perte de paquets introduisant des délais importants, trop de couches de caches, pannes difficilement détectables. La moindre erreur peut détruire toute la base. Un accès unique d’une base de données sur un stockage réseau est déjà un exercice de haut vol, réservé à des environnements professionnels très couteux (Oracle, NetApp). Un accès partagé n’est envisageable que sur architecture de type client/serveur, pour lequel SQLite n’a jamais été conçu.

Par : gigi4lm

gigi4lm — Sun, 07 Apr 2013 16:00:01 +0000

Absent de France pendant plusieurs mois d’hiver, j’ai solutionné le problème en stockant photos, catalogue et backup sur un DD externe connecté en USB3.
J’emporte donc le portable et le DD plus un deuxième pour la sauvegarde complète de l’ensemble avec SyncBackFree.
Sur place m’attend l’écran qui va bien, et le tour est joué.
Bien sûr, on est là dans le cadre d’un utilisateur unique.

Par : Gilles

Gilles — Sat, 06 Apr 2013 13:32:08 +0000

Je pense que placer le catalogue sur DropBox est inutilement compliqué et hasardeux, sans compter qu’on est soumis aux aléas des connexions internet, et que les performances ne sont pas à la hauteur. L’article de Seb sur fotopassion.fr est parfaitement clair à ce sujet, contrairement aux gesticulations d’autres rédacteurs de sites que je ne nommerai pas ici.

À la maison ou en studio, je ne vois vraiment pas l’intérêt de pouvoir accéder à un catalogue de cette manière : on utilise un ordi principal, et on se sert du portable pour le travail occasionnel, facilement transférable dans le catalogue principal, avec toutes les garanties de fiabilité et de sécurité… alors, what else ?

Par : Cocagne

Cocagne — Sat, 06 Apr 2013 13:18:07 +0000

Essayons d’avancer sur un préalable mono-utilisateur ce sera déjà pas mal pour aider les malheureux lecteurs de cette nouvelle controverse qui est en train de brouiller les esprits.

Une question subsidiaire toutefois :
En admettant que l’on trouve son compte à laisser les aperçus dans le dossier (coût de l’abonnement et durées des transmissions)

L’option Dropbox est elle toujours proscrire elle aussi ?

Je dis bien en mono-utilisateur qui ne connecte qu’une machine à la fois.

Par : Bernard

Bernard — Fri, 05 Apr 2013 16:33:39 +0000

Je suis d’accord sur le fond de l’article de Gilles, et comme c’est un peu mon domaine je voudrais completer le commentaire de Pierre.
Il faut distinguer 2 niveaux d’utilisation :
1) l’utilisation multi-machines, par ex un ordi de bureau et un portable, par un seul utilisateur. Cela peut etre très utile en pratique, et beaucoup le demandent.
SQLite version 3.x possède les mécanismes de vérouillage internes qui permettraient de bloquer toute la base de données, comme maintenant (fichier .lock) mais sans faire appel à des mécanismes extérieurs de OSX ou de Windows. Ce vérouillage global est relativement simple à programmer, mais Adobe le fera-t-il ? That is the LR 5.X question.

2° l’utilisation multi-utilisateurs, ou il faut gérer les conflits d’accès à un niveau beaucoup plus fin, ce qui représente une programmation beaucoup plus délicate, surtout sur un programme non prévu à l’avance. SQLite 3.x possède les mécanismes nécessaires, mais je pense qu’Adobe ne le fera jamais avec LR, il s’agit d’une autre dimension d’utilisation, de prix, etc..

Par : Gilles

Gilles — Fri, 05 Apr 2013 12:53:16 +0000

Pierre,

Non, il n’y a pas de mélange entre l’accès concurrentiel et l’utilisation en réseau du catalogue, mais les deux sont forcément liés.

Les sites que j’évoque ont au moins eu l’honnêteté d’être très clairs quant aux accès concurrentiels, en soulignant qu’ils sont exclus.

Mais c’est également une bonne occasion d’en parler et de dire pourquoi Lightroom ne le permet pas, et ne le permettra pas, tout au moins avec l’architecture actuelle.

Par : Pierre

Pierre — Fri, 05 Apr 2013 11:08:10 +0000

Il me semble que dans tous ces échanges on été quelque peu mélangé les notions :
- D’utilisation en réseau
- D’utilisation concurrente d’un même catalogue (ce qui implique un réseau).
Il est évident que LR n’est pas aujourd’hui en mesure d’être utilisé de manière concurrente, du fait de SQLite et de l’implémentation LR associée, et qu’une telle utilisation est à proscrire.
Pour cette évolution attendue je ne pense pas que ceci induise un surcout significatif : il existe des moteurs de base de données open source qui répondent aux exigences, et l’adaptation du code de LR à un accès concurrentiel n’a rien de bien complexe pour un développeur aguerri. Après ça… les politiques tarifaires des éditeurs sont imprévisibles. Réponses avec la version 5 ?

Par : Gilles

Gilles — Fri, 05 Apr 2013 09:37:28 +0000

« Dans ce cas, qu’ils le prennent pour eux-même et qu’ils ne fassent pas de prosélytisme sans mettre suffisamment en garde les utilisateurs potentiels contre les risques encourus. »

Oui, c’est bien ça le le fond du problème, et de la part de professionnels, c’est inquiétant.

Par : FX Belloir

FX Belloir — Fri, 05 Apr 2013 07:59:45 +0000

Bien qu’alléchant au premier abord, il serait dommage de compromettre des années de travail en change de l’agrément de travailler en réseau.
Lr n’est aujourd’hui pas conçu pour ça, c’est clair.

On peut toutefois comprendre que certains soient prêts à prendre ce risque.
Dans ce cas, qu’ils le prennent pour eux-même et qu’ils ne fassent pas de prosélytisme sans mettre suffisamment en garde les utilisateurs potentiels contre les risques encourus.