Besoin d'infos détaillées sur le catalogue de LR

[restoc]

Bonjour,

Je cherche à préparer une nouvelle config de gestion de ma ( grosse) base de données ( images et méta très détaillées) sur une longue durée.

Le pb de la pérennité long terme de la solution et la robustesse de la gestion du catalogue, la non-prolifération de petits fichiers annexes sont quelques uns des critères avec bien sûr le caractère ouvert et portable du catalogue est une condition.
Je cherche donc soit un très bon site technique ou bouquin sur cet aspect un peu souterrain de LR.

A noter que seule la fonction catalogue/tri/archivage/gestion de conf locale ou distante de LR m'intéresse.

Si qqn connaît merci d'avance de ses lumières.

[baséli]

La pérennité de la solution est identique à la pérennité de LR... Je ne me ferais pas trop de souci à ce sujet, dans la mesure où si LR est distancé, le remplaçant proposera forcément une reprise des données de LR.

La base de données de LR est stockée dans un seul fichier. Il n'y a pas de petits fichiers annexes si tu n'actives pas les XMP. La base de données est construite avec SQLite, c'est open source, solide, pas de problème particulier. Si tu veux comprendre l'organisation des tables, on sort franchement du domaine de la photo. Par contre cette organisation n'est pas ouverte ni documentée, et même s'il est possible d'aller voir et comprendre ce qu'il y a à l'intérieur si on touche un peu sa bille, n'importe quel changement est totalement à la main d'Adobe (c'est logique et normal) et rend tout utilitaire lié à cette base ultra fragile. Adobe documente par contre des API si on veut accéder à la base.

Pour l'archivage, il est indispensable de savoir qu'il n'est pas sûr d'archiver une base de données en fonctionnement. C'est pour cela que LR te propose de faire une copie de la base, copie que l'on peut archiver en toute sécurité même si LR tourne pendant l'archivage.

Enfin dans la mesure où cette base est mono-utilisateur et référencée en permanence par LR, il est préférable de la mettre à un endroit très rapide d'accès: SSD sur la machine et pas vieux DD 5400tours externe branché en USB 2 sur un NAS en réseau par Wi-Fi 

A mon avis, tu sais maintenant tout ce qu'un utilisateur doit savoir sur la technique de la base de données de LR.

[restoc]

Merci Baséli, Cà me dégrossit effectivement le pb car j'ignorais que c'était basé sur SQlite et qu'Adobe documente des API.

Ayant eu l'expérience du ... non-passage complet  Bridge -LR je préfère regarder comment être indépendant d'Adobe sur ce point, car rien ne garantit que le catalogue LR restera en l'état ad vitam aeternam.

[Samoreen]

Bonjour,

Je confirme qu'avec une bonne expérience des bases de données, la structure du catalogue Lightroom, bien que beaucoup plus élaborée que celle du catalogue Capture One - carrément rustique - , est relativement facile à comprendre avec des noms de tables et de colonnes presque tous auto-explicatifs. Cela m'a permis en quelques occasions d'aller corriger à la main, à l'aide d'un bon outil comme SQLite Expert Personal, 2 ou 3 problèmes ou simplement d'aller chercher une info particulière que Lightroom ne voulait pas me donner.

On peut regretter que les données de réglages soient stockées en clair, en mode texte, exactement comme dans les XMP. Un stockage binaire aurait certainement allégé le poids de la base, permis un accès plus rapide aux réglages et optimisé l'occupation mémoire. L'idée que pour accéder aux paramètres d'une image, il faille d'abord lire un champ texte de type XML, exécuter le parsing de ce texte et ensuite parcourir l'arbre afin d'accéder à chaque paramètre perturbe l'ancien développeur qui est en moi. Mais bon, c'est comme ça que l'on code en ce 3ème millénaire. On se vautre, il y a des ressources et le chef est pressé.

Le reverse engineering de cette BD ne pose pas de problème majeur et je suis d'ailleurs étonné qu'aucun utilitaire permettant de réaliser sur ce catalogue des opérations statistiques non proposées par Lightroom n'ait encore été publié. Non, non, je me serais bien lancé il y a quelques années mais j'ai promis à ma chère et tendre de ne plus jamais coder. Cependant, il est vrai que la structure de cette BD change à chaque version majeure de LR et qu'il n'est pas interdit de penser qu'ils décident un jour de changer de moteur. Un développeur tiers sera confronté à ce problème (mais ne le sont-ils pas déjà tous ?).

[baséli]

car rien ne garantit que le catalogue LR restera en l'état ad vitam aeternam.

Samoreen, moi et des dizaines de milliers d'informaticiens peuvent même te garantir le contraire!

[restoc]

Merci aussi Samoreen , 

Merci. C'est déjà un peu rassurant de savoir qu'on peut mettre le nez dans la structure de la BD pour regarder. Le pb est effectivement très ennuyeux si à chaque nelle version, Adobe modifie la structure et pas seulement le nb de champs.
Si qqn avait le courage de faire un outil externe pour ne serait ce que regarder et faire qqs modifs la BD ce serait rassurant... On l'encourage tous et on est prêt à lui signer un mot d'excuse pour Madame !

C'est vrai que celle de C1 apparaît quand même limitée. Cà peut se comprendre en venant du Moyen Format où ...on compte les photos à l'unité !

On se demande bien comment font actuellement les grosses BD par ex de l'Equipe, de Match etc. Ce serait intéressant au moins au niveau culturel.

[Samoreen]

On se demande bien comment font actuellement les grosses BD par ex de l'Equipe, de Match etc. Ce serait intéressant au moins au niveau culturel.

Ils n'utilisent pas SQLite mais des SGBD professionnels (SQL Server de MS par exemple).

[restoc]

Ils n'utilisent pas SQLite mais des SGBD professionnels (SQL Server de MS par exemple).

Et probablement deux ou 3 ingénieurs systèmes à plein temps.

[THG]

Cependant, il est vrai que la structure de cette BD change à chaque version majeure de LR et qu'il n'est pas interdit de penser qu'ils décident un jour de changer de moteur.

C'est peu probable, Lightroom a plus de dix ans maintenant et, structurellement parlant, il ne changera quasiment plus, rejoignant ainsi Photoshop sur l'autel des produits qu'on ne peut plus bouleverser (souvenez-vous du test Lr 6.2).

De plus, Adobe se tourne résolument vers de nouveaux horizons avec Nimbus, dont on trouve les prémices dans Lr Web/Mobile ou des choses plus anciennes comme Revel ou Photoshop.com, qui ont servi de banc d'essai à grande échelle. Ce qui ne veut pas dire que Lr est abandonné ou mis de côté, bien au contraire.

[baséli]

C'est peu probable, Lightroom a plus de dix ans maintenant et, structurellement parlant, il ne changera quasiment plus, rejoignant ainsi Photoshop sur l'autel des produits qu'on ne peut plus bouleverser (souvenez-vous du test Lr 6.2).

Sauf s'ils décident de faire de LR un logiciel multi-utilisateurs, auquel cas ils seraient bien obligés. Ce qui n'implique pas qu'ils bouleversent la structure des tables. Mais je doute fort de l'existence d'un marché pour cette fonctionnalité, et eux aussi manifestement.

Cependant la fonction du multi-utilisateurs, si elle existe un jour, risque fort de passer par le nuage, où elle est techniquement "naturelle" et bien plus simple à gérer pour les utilisateurs. Je suppose qu'Adobe dispose d'administrateurs système un peu plus compétents que le photographe moyen...

[THG]

Baséli, oui, tu vois très juste. La notion de multi-utilisateur passera par le cloud, et je crois qu'on verra arriver ça plutôt dans Nimbus que dans Lr.

[baséli]

Baséli, oui, tu vois très juste. La notion de multi-utilisateur passera par le cloud, et je crois qu'on verra arriver ça plutôt dans Nimbus que dans Lr.

Ben merci! Ce sont juste des remarques issues de la technique informatique, quand on comprend bien comment ça marche, certaines choses sont assez évidentes. Ce qui ne veut pas dire non plus que ce soient les bons choix commerciaux ou fonctionnels, je n'en sais rien, sinon je bosserais chez Adobe...

[THG]

Ben merci! Ce sont juste des remarques issues de la technique informatique, quand on comprend bien comment ça marche, certaines choses sont assez évidentes. Ce qui ne veut pas dire non plus que ce soient les bons choix commerciaux ou fonctionnels, je n'en sais rien, sinon je bosserais chez Adobe...

Comme je le disais un peu plus haut, Lr fait désormais partie des classiques qu'Adobe ne peut plus se permettre de restructurer à cause de la base installée. Et un format de BDD à accès concurrentiel est quelque peu passéiste, en regard des promesses de la synchro Cloud, et Lr n'aurait pas le même coût.

[Samoreen]

En fait, SQLite supporte les accès concurrents. C'est le code de Lightroom qui n'utilise pas cette fonction.

Contrairement aux SGBD "poids lourds", SQLite sérialise les accès concurrents, c.-à-d. qu'il les traite à la suite les uns des autres avec blocage temporaire des enregistrements en cours d'utilisation. Ce n'est pas acceptable dans une grosse structure mais la demande d'accès concurrents par les utilisateurs de Lightroom relève le plus souvent d'accès réalisés par un petit nombre d'utilisateurs sur un réseau local ne comportant que quelques machines.

Il ne s'agirait donc pas d'une évolution massive mais de revoir le code en mettant en place les protections habituelles afin d'éviter les collisions (sémaphores, mutexes, etc.), protections qui sont évidemment absentes à ce jour. Ce n'est pas très compliqué à faire. Il faut juste le vouloir...  .

[baséli]

revoir le code en mettant en place les protections habituelles afin d'éviter les collisions (sémaphores, mutexes, etc.), protections qui sont évidemment absentes à ce jour. Ce n'est pas très compliqué à faire. Il faut juste le vouloir...  .

Et on aurait les bugs d'interblocage habituels aussi 

Sans compter ce n'est pas fiable sur Windows (une paille), cf question 5 de la FAQ. J'entends d'ici les hurlements au scandale si LR tombe dans ces bugs là 

[THG]

Oui, il me semble bien qu'il n'était pas question pour Adobe de s'engager sur la voie de l'accès concurrentiel en raison de problèmes de fiabilité d'une part, et d'un trop grand risque de déconvenues côté utilisateur. Quand je vois, en formation, dans mon forum ou encore chez les nombreuses personnes face à moi lors de mes présentations Lr au Salon, les multiples problèmes liés à l'incompréhension du principe du catalogue, j'ose à peine imaginer ce qu'il pourrait en être si, en plus, on avait la possibilité de travailler à plusieurs sur la même base de données.

Je crois sincèrement que la meilleure voie, aujourd'hui, est de placer la base de donnée dans le cloud, et que celle-ci soit gérée par le système, et c'est ce que fera Nimbus. Bien sûr, ça implique une bonne connexion internet, qui n'existe pas partout, mais, à moment ou à un autre, il va quand même falloir avancer. Et ceux qui veulent gérer leur catalogue pourront le faire avec Lightroom, comme avant.

[frmfrm]

Sans compter ce n'est pas fiable sur Windows (une paille), cf question 5 de la FAQ. J'entends d'ici les hurlements au scandale si LR tombe dans ces bugs là 

Je ne sais pas de quoi il est question dans la faq, mais j'ai un problème avec adobe et sqlite.

Régulièrement depuis que j'ai installé lightroom, je perds mes autoris

[frmfrm]

Mince le coup est parti trop vite :-)

Sans compter ce n'est pas fiable sur Windows (une paille), cf question 5 de la FAQ. J'entends d'ici les hurlements au scandale si LR tombe dans ces bugs là 

Je ne sais pas de quoi il est question dans la faq, mais j'ai un problème avec adobe et sqlite sur windows 10.

Régulièrement, depuis que j'ai installé lightroom, je perds l'autorisation d'utiliser mon premiere pro cs5.5 ( à cause d'une corruption du fichier cache.db ) . Re-rentrer le numéro de série de première n'est pas suffisant pour régler le problème. Il faut que je remplace le fichier par une archive.

[gigi4lm]

...
Je crois sincèrement que la meilleure voie, aujourd'hui, est de placer la base de donnée dans le cloud, et que celle-ci soit gérée par le système, et c'est ce que fera Nimbus. Bien sûr, ça implique une bonne connexion internet, qui n'existe pas partout, mais, à moment ou à un autre, il va quand même falloir avancer. Et ceux qui veulent gérer leur catalogue pourront le faire avec Lightroom, comme avant.

Et oui, c'est là que le bât blesse. On est loin, en France et ailleurs, d'avoir une couverture nationale avec un débit correct. Bon, comme tu dis il faut bien avancer mais au début il y aura des laissés pour compte.

[Samoreen]

Et on aurait les bugs d'interblocage habituels aussi 

Là, ça dépend de la qualité de l'analyse et du programmeur. Il suffit d'avoir de la méthode. Et dans le cas évoqué, la gestion de la synchronisation ne serait pas très compliquée.

Sans compter ce n'est pas fiable sur Windows (une paille), cf question 5 de la FAQ. J'entends d'ici les hurlements au scandale si LR tombe dans ces bugs là 

Qu'est-ce qui n'est pas fiable sur Windows ? Les mécanismes de communication inter-process ? Les objets de synchronisation (mutexes, semaphores,...) ? Je les ai utilisés pendant des années pour des applications complexes et je n'ai jamais eu de problème particulier (sauf erreur de programmation).