Organization features

Comments

6 comments

  • Avatar
    Angela Andrieux

    Hi Mike,

    Thank you for the thoughtful feedback! I'll make sure it gets into the hands of our developers.

    0
    Comment actions Permalink
  • Avatar
    Sherwood Botsford

    There are some issues with using a network drive:

    * Network is slow compared to local hard drive.  If you are going to process a raw file, you're moving megabytes back and forth.  Not impossible, but it will make for a noticeable pause.  Wi-fi connections may be horrid.

     

    * Multi-user database is old hat.  That aspect of it won't be a problem.

    * Cache thumbnails locally so that image selection is fairly fast.  Have an option so that you can cache the entire catalog's worth of thumbnails.

    * File locking.  You don't need to do this at the library level, only at the file level.  This can be tricky to do well.
    >> If I have 3 files open and my computer crashes, do those files remain open?
    >> Can I manually delete a lock?

    If I were implementing it it would work something like this:

    I try to open a file for editing.  

    Server program checks.  No one is using that file.  Creates file lock file.
    Tells client program "You can edit this file."

    Client computer crashes.

    Other client computer tries to open same file. 

    Server says "I have a lock file for client1.  I better check."

    Sends a request to client 1. "Are you still using file xxxx" 

    Client 1 doesn't answer -- new lock is granted to client 2.
    Cleint 1 does answer, and says, "Yes I am"

    Server tells client 2 that it is still in use by username on client 1.  

    Option:  Open read only
    Option: Open a new version
    Option:  Tell you when username is done.

    0
    Comment actions Permalink
  • Avatar
    Mike Bernhardt

    Apparently the issue is that LightRoom uses SQLite, which has this limitation. PLEASE go another direction and make your library friendlier to multiple users. Right now I struggle along with iPhoto because it sort of works to do this, but then everything has to be exported for use in Luminar, or LR for that matter.

    1
    Comment actions Permalink
  • Avatar
    Mike Bernhardt

    "Network is slow compared to local hard drive."

    Absolutely true, but having the option would make a huge difference for me and my wife. We aren't professionals and our network is reasonably fast. As long as the software can handle it reliably, we're fine.

    0
    Comment actions Permalink
  • Avatar
    Sherwood Botsford

     

    Gives a good comparison of SQLite, MySQL and PostGres.

     

    https://www.digitalocean.com/community/tutorials/sqlite-vs-mysql-vs-postgresql-a-comparison-of-relational-database-management-systems

    Nutshell:  SQLite has no user managment, and is not multi-user.

    MySQL is not fully reliable, and development is stagnant.

    PostGres is open source and is standards compliant, but may be slow.

    Wiki has a page: https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

    It's mostly links to the individual page for each.

    ***

    Often what developers do is to put a shim layer between their software and the database.  The program calls the shim. The shim calls the database.  If you have a different database you write a different shim.

    If Luminar did this you could then put in SQLite for the local client, and use whatever for the network server.  With a decent shim layer, then *any* database provider and use the shim API to write an way to use their database with Luminar.

    In addition to use a different database you need to translate the old database into the new one.  If your original database is done right it can be as simple as exporting a bunch of CSV files and importing them into the new database, then rebuilding indexes.

    0
    Comment actions Permalink
  • Avatar
    Sherwood Botsford

    I don't think network speed will be an issue on most home networks.  a 4000x6000 pixel image is about 12 MB compressed which is about 100 mbit.  So on 100 Mbit/s networks, it would be 1 second to open the file.  On Wifie it would be 5 to 40 times as long depending how far you are from the hub, and how many other people are using it.

    If you are doing a batch operation it could get sticky.

     

    Depending on how Skylum implements its DAM, it could be messy too.

     

    Ideally a DAM sstores what it can IN the file as well as in a database.  That may make updating a big batch of files very slow.

    What *should* happen is that local client updates database by sending an update to the server.   The server then updates the image.  This makes more of the image traffic local, and you can use OS support for updating just a portion of the entire image.

    This may mean that the database image locking will be different from the edit image lock:  In the first one, you are quite likely to need to access a bunch of images at a time, but often can use a local large thumbnail for it.  In the latter you will usually only have one or a few images open at a time, but for a longer period of time.

    0
    Comment actions Permalink

Please sign in to leave a comment.