[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