P: Allow Catalog to be stored on a networked drive.

Last year, I submitted a feature request that was received by Adobe to implement a multi-user version of Lightroom. In this forum, I discovered that the reason this has not been implemented is that the underlying database is SQLite which does not effectively imlement record-level locking. Also a comment given for not considering the now much more standard MySQL was potential cost...but that was dismissed in a subsequent comment.

I am a (volunteer) database administrator at the National Air and Space Museum (NASM) and am coordinator for a major internal database using Microsoft Access. For years, MS Access has had no problem with record level locking and multiuser access. We are converting this database to MySQL and so far have had very good success. Multiuser access in MySQL works well.

If SQLite is the problem, I suggest Adobe seriously evaluate recasting Lightroom to use MySQL.

My personal reason for needing multi-user access is that I maintain a personal database of over 40,000 photos and this is growing very quickly as I add both family and air & space photos (I am also a docent at NASM and share responsibility for training new docents, so a photo database is important in that regard too.)

At home I have Microsoft Home Server and a small 3-client machine network (my machine, my wife's machine, and my laptop.) Currently, we have the Lightroom catalog installed on an USB connected external drive and move it from machine to machine whenever one of us needs to access Lightroom (and that is frequent.) Both my wife and I need concurrent shared access to the same Lightroom database. Record-level locking would prevent use both from working on the same photo at the same time. Being able to install the catalog on the server would greatly simplify life for us (and would help to ensure domestic tranquility by preventing conflicts over whose work is more important or highest priority.)

At NASM, we have an intranet implemented using MS server with Windows clients. We don't currently have Lightroom installed on our machines because it is a single-user application. I certainly would recommend it in a heartbeat if there was a true multiuser version available.

In regard to licensing, I think Adobe should consider a "family license" much like Micorosoft, Norton, McAffee, etc. This would authorize up to say, three concurrent uses of Lightroom using a single license.

Lightroom should also be authorized for organizations by selling licenses for multi-user versions. We certainly would be interested in that for our Education Department.

Please be advised that NASM has NOT authorized me to speak for them or to commit. Since I am a volunteer, any such interpretation of my comments would cause grief to me and to NASM. I appreciate your consideration in considering these suggestions.

Would love to see this functionality implemented. With multiple machines for capture/editing, a shared catalog on a NAS or server is an ideal situation (and saves from having to move a portable drive between machines with the catalog stored on it).

I thought I remembered that's what Jeff Schewe was claiming. I could be remembering wrong (or maybe he was wrong...).

I'd be interested in what reasons you have heard, if you could & would....

Cost was never among the reasons I've heard for not using MySQL.

Any idea what the MySQL commercial license for OEM vendors would cost? If my memory serves me correctly, this option was considered but rejected due to competitive cost concerns (I'm vaguely remembering a post about it on the *other* forum, which you will have a hard time finding since the search is broken there).

It might be worthwhile to consider using a database with a bit more power, such as MySQL.

If I recall correctly, my experiment was a Mac file SMB share with a single Windows XP client. I pulled the cable in the middle of an import and the next time I tried to open the catalog, it was corrupted such that I was unable to fix it in the usual way (doing a SQLite .dump into a new catalog). It wasn't great for performance either, but I didn't investigate that in detail as I was primarily concerned with validating or dispelling concerns about robustness against network failure. Our use of SQLite has changed significantly since then, so it's possible the results of repeating that experiment may be a bit less dire than previously. It's also possible that the (relatively new) WAL mode might be more resilient against this condition. My experiment is more than a little dated at this point. It's probably over 4 years old now.

Please retain a single-user implementation of LR. If you (Adobe) decide to implement a multiuser implementation, make it a separate deliverable.

Most of your customers are unlikely to ever have a need for a multiuser catalog (especially one that supports concurrent update). Please don't foist significantly decreased performance and higher complexity on folks who would receive no benefit from a multiuser implementation.

Dan

This is about the same level of uncertainty I discovered a couple of years ago for another use of SQLite. Thought the SQLite authors refer to "reported" problems of the Windows locking primitives, I found supposed Windows experts dismissing such problems when the server side was implemented by Microsoft, as opposed to a third party. We don't know the details of Dan Tull's experiments -- were they with a Windows client, a Windows file server, or some other NAS common in large companies? Did they invovle concurrent accesses or just randomly dropping the network connection?

Given all this, I don't think we can authoritatively state that a Windows 7 client running with a Windows 2003 file server would be problematic. And similarly, I think anyone who experiments with this should be prepapred for possible problems.

Here's the quote:

Quote:

>FWIW, I did actually add a switch (briefly) to allow support of a catalog file on a network share (basically just lifting the block on it) and managed to corrupt the catalog beyond repair (and if you Google around for my name, you'll find I know a few things about repairing catalogs) when testing it under stress conditions. SQLite is fundamentally dependent on sound file locking guarantees to ensure data integrity and network file shares don't cut it.

>So, while it would be (was) be easy to "just allow it" for power users, I'd basically be committing myself to spending all my time helping people whose catalogs were damaged when their network hiccuped at the wrong moment.

>Which unfortunately means a robust catalog on a network share feature is much harder and more risky than it seems on the surface without even getting into the multiple simultaneous users aspect.

>Dan Tull
Lightroom QE
Adobe Systems