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

"You see - you have manually created a workflow that would mimic the workflow that a production studio needs to implement. Simply, you have taken a hammer to create a shared environment when it was completely unneccesary if Adobe had simply not chosen SQLite."

True, however this can be said for workflow's around the world. People don't name their stuff consistently, does that mean LR needs to add that functionality in too? I believe that these things are just tools in a big toolkit in order to get the job done

"But Stuart - it's clear you DO need a shared environment, I'm simply astounded you argue against it"

No no, not at all, I believe we DO need one absolutely, I just don't think you're going to get one with LR

I don't understand why you simply don't want to discuss the possible improvements. You talk about Mongo DB so you know collaborative sharing of documents on a network, reliably, is possible. Why not think about how LR can take some of that and integrate it to the solution. Not the whole thing, just simple add ons that will help me in my professional life (and keep me as a client of Adobe's).

"I know it would, that's why i said it 🙂 But I think it's up to the individual to search out these things. "

What? It is everybody's job to find how to add a new room to their home? Change the oil in their car? Make a energy efficient refrigerator?

We pay for software because our job is to photograph, not program or assemble complex software solutions... Why do you tell me it is my job to look for solutions, I am willing to pay for a ready-made, supported one. All I am asking is to have a constructive discussion on possible improvements to LR to make my life easier.

I am not suggesting to do all of this, again, just see if Adobe can do a few quick wins here and there and improve the user experience, maybe pros will pay extra for that and the regular users will be happy with the "normal" edition. I would certainly consider paying more for more and I know I am not the only one.

There IS a need, I know for a fact that I NEED these improvements. I am very very technical savvy, I can create a system that does that, but I wish it was built-in and supported by Adobe and not through a collection of software. I don't have time for this, I want to focus on photography.

Again, why not just talk about potential improvements instead of loosing time arguing on not doing it.

I have to chime in again, it's monday, and I like to poke a hornet's nest *smiles*

so - database functionality and that "you don't need it in truth"

I'm siding with Andre here Stuart - as I'm a staunch supporter of Lightroom's *cough* database functions needing to be more - well - databasey....

On the one hand I do hear what you're saying about the possibility of a shared environment not being needed by all, and that workflows for people need to be adjusted for the software they work on - however... if that's the case - just don't "share it".

There's a massive difference between "loading a module/add on/feature" - like maps or book or web - than there is having a latent ability to simply "share".

You keep arguing that your convoluted workflows that you have - with your ssd's, and cf's and scripting, and backing-upping, and sans and sharing and exporting and what have you - are awesome for your work flow, and because YOUR system works, you don't see the need to have lightroom's database work - as a database.

It's a self defeating argument.
You see - you have manually created a workflow that would mimic the workflow that a production studio needs to implement. Simply, you have taken a hammer to create a shared environment when it was completely unneccesary if Adobe had simply not chosen SQLite.

The core FUNCTION of a database IS to have this function - Adobe simply managed to break it.

I understand when you say that the core features should be photo related, and that's all this thread has been trying to get Adobe's attention on.
We have X Million photos we need in a collaborative environment, and teasing us with a database core that doesn't have the ability to be "shared" is just - well - wrong.

Your workflow that you have described ONLY works for a single user - and it's a logistical mess to learn your work flow - because you have to have access to just so very many things to make it happen.

Your thoughts that implementing a proper database function of sharing would create more support issues is simply off the mark - because if one uses a tried and true engine, then you find you can account for almost all the current issues right out of the box. It seems to me that your workflow introduces far more variables for corruption and loss, not to mention having so many areas for so many catalogues just makes for a nightmare trying to sync it all without an "oh sh*t i just overwrote something I needed".

Adding features to lightroom like the "book feature" is simply a gimme for sales for other companies, and those module DO impact lightroom's performance - so no - I cannot belive your efforts to say that allowing LR to be a database would hinder it's performance MORE than the fluffy crap adobe has added to make this pro software appealing to someone who lurvs Instagram.

Lightroom is built to be a database with tweaking - it's not photoshop, I don't want it to be photoshop.
Lightroom cannot replace bridge until they add support for all files like ai, or gif, or what have you.
It most definitely cannot replace bridge until it can access shared folders.

Lastly, let me ask a general question here - Just what do you think the database is full of to "suffer such impending doom of corruption?
- it's a database of metadata and tags - oh and the reference to what "filter" is applied - that's it.
like 2k of data per photo.
What is all this fear of corruption?

You're not going to loose your previews, and even if you did, who cares? They are temp files - cache, nothing more. So all adobe had to do was make the a sharable database, a strategy (likely built in) for back up and error checking, and the ability to have a network folder - with a "local" active temp file for edits, that get saved back to the shared folder's cache folder.

Really, it's a simple 1 2 3 without having to reinvent the wheel.

SO to sum up - LR needs to be LR as it's advertised - for a professional working environment.

In today's world we HAVE to collaborate and share our resources to stay effective and efficient - and as a result Lightroom should not have been crippled out of the box. If you are only ONE photographer, and have no need for this, then don't share.

But Stuart - it's clear you DO need a shared environment, I'm simply astounded you argue against it.

"Realistically, maybe not possible, at least in the short term. But why not look at integrating some of these in the product"

There's no need, they all work together fine without adding in complications like shareholders and botton line

"Why not? Why not at least consider it and not reject the idea completely? (remember this IS the "Ideas" forum). That would be a fantastic solution"

I know it would, that's why i said it 🙂 But I think it's up to the individual to search out these things.

Lets hire out the dev guys on each of these programs and come up with a single program that does all that good stuff in one..

That's a lot of dollar, and certainly a lot more than the £80 price tag of LR

I don't see your point about more corruption issues, etc. It is what databases are for and there are great solutions out there, managing immensely larger databases properly and for decades. I worked for many years in the software industry and there are so many good database solutions out there, that is not a valid point to say that Adobe should not invest time in sharing and backups. To the contrary, continuing with SQL lite and a single user design may eventually mean more support and "corruption issues" as people will grow with LR, end up with 1000K+ image libraries and start complaining that the software does not cope.

The more things you put in the way, the more people are going to trip up. It's fine for Pro users that have a grasp on workflow and a best practise, but what about the myriad home and everyday users of LR. A lot of guys believe the word 'Server' will save their lives, in fact it makes it worse. Writing data over am ethernet connection between two drives is more reliable than writing local data? I don't think so. Certainly a way to share would be advantageous, thus giving more collaboration, in fact I have a piece of software for that too 🙂 It runs on Mongo DB

http://focalpointserver.com/

"Of course it would be amazing to combine the ingest capabilities of Photo mechanic, the cataloging of LR, editing of PS, backing up and mirror options of ChronoSync, the speed of SSD drives, network ability of a SAN and sharing/search functions of a full blown SQL DB. But in one program?"

Why not? Why not at least consider it and not reject the idea completely? (remember this IS the "Ideas" forum). That would be a fantastic solution.

Realistically, maybe not possible, at least in the short term. But why not look at integrating some of these in the product? I never meant to say "replicate the network ability of a SAN", just that the concept of master files and catalogs should be more tightly related. LR could be "conscious" of my working drive vs my backup drives and help manage the synchronization. If the backup drive is a SAN configured in RAID 10, it doesn't need to care. I never either mentioned speed of hard drives, just that SQL lite is NOT fast and cannot be shared/centralized.

You mentioned ChonoSync, I use it. I still wish that when I moved or renamed a file, it does not stupidly delete the "old" and copy the "new", when all is needed is to replicate the rename operation. That would only be possible if LR did it, not ChronoSync's fault. And I also wished that when I rename a folder and my colleague creates a new file in that folder/project on his laptop, LR would understand that I don't want to synchronize that file back in the old folder, but add it to the newly renamed folder. All details, but they add up and are frustrating after a while.

Anyways, all I am saying is that there are missing features. I am not hoping Adobe adds all these "enterprise" features in LR but at least beef up the collaborative and backup/replication ones. There are already a semblance of multi-user features and backup functions, they only need more work to be really effective.

Then let me disagree 🙂 LR is primilarly a cataloging/organizational software. The editing features are relatively

Indeed, that's why god gave us Photoshop for anything that wasn't minro tweaking. Personally I edit my images as much as the next person, ie not a lot. Convert, Crop if needed, bit of contrast, WB tweak if need be, bit of sharpening then out. LR is perfect for that - With the inclusion of the Nik toolset :)

I don't think it promises a full end to end workflow at all, it can certainly facilitate that but other tools and experience is needed. As I mentioned earlier, there's never a one stop shop with software

I guess i'm just saying that you don't need it in truth. The hardest thing to do when looking at people's workflow, is changing that person's mind on what they think they need. It's a constant challenge for me when I put in these ideas to clients.

Of course it would be amazing to combine the ingest capabilities of Photo mechanic, the cataloging of LR, editing of PS, backing up and mirror options of ChronoSync, the speed of SSD drives, network ability of a SAN and sharing/search functions of a full blown SQL DB. But in one program?

You are basically adding to my point. I should have a tool to do that properly, not have to copy files around and do anything manually. The worst backup solutions are the manual ones. I should be able to import in LR, do my "creative work" and be reassured that LR is doing the backup part for me in the background. I can rely on Time Machine or other commercial tools for backing up, true. But that only takes care of the files and not the catalog information. Where is my solution for the catalog backup? The basic catalog-copy function that is called a backup solution is not really smart. It basically copies the catalog file to a new file. Does not keep deltas, does not help me when I moved files around, etc.

I travel a lot. I could buy hundreds of CF cards I suppose, but it would be far from a good solution. I need to import images from the card(s) and automatically backup the images elsewhere. I also need to backup my precious catalog information as a lot of stuff is in there. But, shoot, nothing exists in LR to do that simply...

The software industry had that problem for years and came up with Source Control Management solutions that are fantastic and I don't see why LR could not start taking ideas there. That is already existing technology, not rocket science...