Image storage in Database, FTP Server

fcarlier · Post by **fcarlier** » Thu Jun 21, 2007 2:44 am

Hi,

I'm working on providing functionality for storing the images in the Open Dental database itself, or on a FTP server. This is to improve compatibility with Linux.

This requires refactoring of ContrDocs.cs in OpenDental. I am currently implementing this change as such:
1. I created an IImageStore interface. This is the common interface for all classes that provide image storage functionality. It exposes methods such as "OpenImage" and "StoreImage". Nothing special.
2. I created a FileStore class. This class contains all the functionality currently present in ContrDocs.cs, that is, storing files on disk.
3. In ContrDocs, I added a IImageStore imageStore field. That field can be used to access the images.
All code is isolated in a separate DLL, but can quickly be moved back into any of the other DLLs.

Of course, there are more modifications to be made. The UI has to be changed to reflect the possibility for multiple storage providers. This change is experimental, and will take some time to mature.

However, any feedback on this feature is welcome. I'm interested in knowing if a change like this can eventually make it into Open Dental head.

Post by **jordansparks** » Thu Jun 21, 2007 9:32 am

I support moving this to the head as soon as we move to 5.1. Derek is responsible for that module, and it will be under active development for a while, so it may be a little bit of a dance if you're both working on the same area of the program. But it will be nice to have two sets of eyes looking at it and following it closely. I think it's reasonable.

grahamde · Post by **grahamde** » Thu Jun 21, 2007 10:20 am

Storing images in the database has been up for discussion several times in the past. We have traditionally decided to just always keep the images outside of the database in an on-disk location, so that database backups would be faster if one was not concerned with the associated images (the data itself is usually considered to be the most important piece). Additionally, moving the images into the database makes them inaccessible to the common user, and some of our customers expect to be able to view and/or edit customer images outside of Open Dental.
However, I agree that it would make the in-code use of the images easier, and would probably save some disk space if the images were in a database. If we wanted to keep the old paradigm partially in place, perhaps it would be best to store the images in an entirely different database, so the user could still have the option to backup or not backup their images. In effect, the user would have two databases which makeup the data in the application. This would not be so different than the way things are run now (except the users would still have a harder time manually accessing the images if desired).

fcarlier · Post by **fcarlier** » Thu Jun 21, 2007 10:53 am

My main concern now is to create an additional layer so that the data storage is abstracted away from the UI. From there, it should be easier to implement any other storage system.

The reason for storing files in a database or on an ftp server is basically Linux compatibility.

Anyway, if you are okay with the pattern (the IImageStore stuff), I could fine-tune it so it gets ready for inclusion in 5.1.

grahamde · Post by **grahamde** » Thu Jun 21, 2007 11:09 am

fcarlier wrote:My main concern now is to create an additional layer so that the data storage is abstracted away from the UI. From there, it should be easier to implement any other storage system.

The reason for storing files in a database or on an ftp server is basically Linux compatibility.

Anyway, if you are okay with the pattern (the IImageStore stuff), I could fine-tune it so it gets ready for inclusion in 5.1.

Yes, I like this implementation, and fortunately I have just finished the work I needed to get done in the image module. However, there may be some bug fixes between 5.0 and 5.1. You may have to keep up on the subversion emails to see if there have been any bug fixes in that time-frame.

drtech · Post by **drtech** » Thu Jun 21, 2007 6:53 pm

I do like being able to access the images outside of OD...

currently we still e-mail, and import multiple images and cut, paste multiple images from our digital camera to the pt folder from a windows explorer window

...but i understand to make it more linux compatible it makes sense....
how come it isn't linux compatible using a file system the way it is? (It works fine windows to linux like I have using Samba, but is this for more complicated systems?)

one BIG advantage I see of leaving it out of the data base is you still have complete access to the images if you want to use them outside of OD without having to EXPORT or whatever it would take...

Post by **jordansparks** » Thu Jun 21, 2007 8:05 pm

fcarlier certainly wasn't suggesting replacing the current default image storage method. I actually never even thought of abstracting it the way you suggest. I'm interested to see how you do it.

fcarlier · Post by **fcarlier** » Tue Jul 24, 2007 12:33 pm

I'll be away until August, 4th, so won't be working on this feature in meanwhile.

As for the NUnit test project, I could check in the NUnit dll's into SVN.

Post by **jordansparks** » Tue Jul 24, 2007 1:41 pm

Or maybe it works fine to have the NUnit test project not be part of the solution. Either way seems like it would be fine.

Good to know that you'll be away.

fcarlier · Post by **fcarlier** » Tue Jul 24, 2007 2:42 pm

Yeah, I could keep the NUnit tests in a seperate solution (a solution is required because of the references to other projects). That way, the main solution doesn't get cluttered with many projects. I'll do it that way when I get back.

Frederik

Open Dental

Image storage in Database, FTP Server

Image storage in Database, FTP Server

Image File Storage

Image Store Functionality