Database upgrade

[someothername]

SQLite is just what it implies, a light weight database that uses the Structured Query Language. It bills itself as small, fast, and reliable and is in fact used as the backend storage for many applications, including the firefox browser. It's public domain and open source and is constantly being improved; Adobe is one of the sponsors. But it does not turn up on PC mag's review of databases, even though MySQL does, which is also open source and much more widely used, and, I suspect, more mature.

I'd like to see two things: First a better database engine. One corrupted database per 1',''' openings is maybe acceptable, but what I've seen in the Lightroom forums sounds to me more like a corruption every five or six thousand Lightroom start ups. It's happened to me three times, but fortunately, it's recovered each time. A professional who is depending on this engine to organize his or her work simply can't afford to have that happen more than once.

Second I'd like to see database access of some kind in the SDK. Unlimited read only query access for sure, and probably some limited tables that can be modified from the SDK. And possibly some way of adding tables and stored procs so that I could create an export plugin for example that puts prices, names and address of who I sold those pictures to.

This is important to me because I would like to use Lightroom as my photography database and not have to worry about planning for when it crashes on me. It's also important because I can see a lot of possibilities for plugin writers that will make Lightroom a great tool.

I've put this on the Adobe feature page.

 

[Mark Sirota]

SQLite and mysql are vastly different. The biggest is that SQLite is serverless, mysql isn't. I'm not familiar with PC Mag's review, but these two products really don't compete with each other.

I'm not sure the DB engine has much to do with the corruption. These might not be corrupt databases, but corrupt data. The DB itself might be fine, it's the data inside that's not accurate or consistent or whatever. (Or you may be right. I don't know.)

Your suggestion of DB access through the SDK would be cool; certainly submit that as a feature request (there's a link to the form on the blue bar in the page header). You can use SQLite directly, but don't try that while LR is running, and be sure you've got good backups!

 

[someothername]

SQLite and mysql are vastly different. The biggest is that SQLite is serverless, mysql isn't. I'm not familiar with PC Mag's review, but these two products really don't compete with each other.

Point taken, there is a difference between a serverless database and one that is server based. However, most of the others reviewed on PC Mag were in fact serverless, they just cost money, anywhere from $1', to $4','''.
http://www.pcmag.com/category2/',28'6,4177,''.asp

I'm not sure the DB engine has much to do with the corruption. These might not be corrupt databases, but corrupt data. The DB itself might be fine, it's the data inside that's not accurate or consistent or whatever. (Or you may be right. I don't know.)

It's impossible to say whether it is the database engine or the data put in there that is causing these crashes. If the data is in fact bad, then there must be bugs in the Lightroom software. I don't know anything about the internal system architecture of Lightroom.

There are three basic ways of building a database centered system. One is to put the business rules that guarantee data integrity in the database through foreign keys, triggers and so forth. Another is to simply use the database as a storage dump and have all the data integrity managed by business rule logic in the application. The third is usually some combination of the two, with basic data integrity enforced by internal database rules and additional integrity ensured by code in the application that puts data into the database. Since Adobe is an application oriented company, I rather suspect the second is most likely the underlying design.

If that's the case, then swapping in a more robust database engine is not going to solve the problem. Which means we probably need a 2.1 version that addresses whatever is allowing bad (inconsistent or whatever) data to get stored in the database.

Your suggestion of DB access through the SDK would be cool; certainly submit that as a feature request (there's a link to the form on the blue bar in the page header). You can use SQLite directly, but don't try that while LR is running, and be sure you've got good backups!

I have submitted it as a feature request. However, I found another post on here yesterday that indicates someone at least has dug into and is able to pull data out of the database.
http://imageingester.com/
The LRViewer tool does that. The LRVMaker next to it sounds like a winner, too.

 

[Brad Snyder]

LRViewer & LRVMaker

Yes, we've been recommending those tools for some time here. Marc Rochkind, the author is a member and contributor here.