[APBeta] DSS Image library

Paul Rodman paul at ilanga.com
Mon Mar 16 19:59:01 PDT 2009


On Mar 16, 2009, at 07:01 PM, Bob wrote:

> As we add images and images in higher resolution and then add larger  
> image
> fields, it looks to me as though this in inevitable.  If there is  
> still some
> mechanism for the user to periodically go though and weed out  
> unwanted ones
> I see the single database file as a plus.

The user interface would not change from what it is now. It's just the  
machinery in the cellar that would change.

> What might seem like a large file
> now will just be a medium size one tomorrow and a small one next  
> week. It
> looks to me like backing up would be easier, one large file as  
> opposed to
> directory tree and all it files. One of the bad things about  
> restoring a
> database is to find out some index or control file got left out in the
> backup process. There would be no need to worry about the directory
> structure when restoring a single file. So in my opinion this would  
> be a
> good idea.
> SQLite is what Carted du Ciel V3 is using. Asteroids and comets seem  
> to run
> ok in that system.

V2 plan documents, resources, and observation databases are all SQLite- 
based. They are turning out to be quite robust.

Paul R.


>
> Bob
>
> -----Original Message-----
> From: apbeta-bounces at lists.astroplanner.net
> [mailto:apbeta-bounces at lists.astroplanner.net] On Behalf Of Paul  
> Rodman
> Sent: Monday, March 16, 2009 8:47 PM
> To: AstroPlanner Beta Testers
> Subject: [APBeta] DSS Image library
>
>
> Folks,
>
> Currently, in V1 and V2, the DSS/user image library consists of a
> whole mess of image files, other files containing info pertinent to
> those images, and an image index, which is really just a database of
> file paths.
>
> This way of doing things has/had the advantage of being flexible,
> friendly to incremental backups, etc. However, it's also slow, and has
> a lot of spaghetti code surrounding it which is buggy and difficult to
> maintain/extend. I'm getting a lot of bugs reported related to this
> feature.
>
> What I propose is to create a single-file database of the images and
> attendant information. This would have the advantages of much faster
> access, less chance of corruption, smaller and more maintainable code,
> and easier extension to support new sources, etc.
>
> The disadvantages would be be (a) those of any large single file, such
> as backing up, etc., a single corruption damaging the entire
> database*, etc., and (b) non-backwards-compatibility with V1.6.
>
> I don't see (b) as a problem going forward.
>
> The size of the file would be approximately the size of the DSS Image
> Cache folder now, so you wouldn't be saving/losing disk space.
>
> I would probably read the current cache to create the initial
> database, so you wouldn't have to download all those pesky images  
> again
>
> What do you people think about this? Please air your views here or
> privately with me.
>
> Paul R.
>
> * I would be using the SQLite database format, which is very robust
> and efficient - in both speed and use of disk space.
> _______________________________________________
> APBeta mailing list
> APBeta at lists.astroplanner.net
> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net
>
> _______________________________________________
> APBeta mailing list
> APBeta at lists.astroplanner.net
> http://lists.astroplanner.net/listinfo.cgi/apbeta-astroplanner.net




More information about the APBeta mailing list