[Kstars-devel] branches/kstars/carbonix/kstars

[Victor Carbune]

> I think it would be better to generate database during build phase and
> install it as data file. The less we touching $HOME the better.

Yes, the database should be shipped as a prebuild file (this was the
idea, I think I made some confusion when I wrote).
I'll move the KStarsDB class probably in the data/tools folder.

There should be, however, a class which manages the interaction with
the database. KStarsDB was my target for this (having the conversion
methods as well). Or, would it be sufficient to let the developer do
the queries manually using the normal Qt SQL Driver provided?

> Now regrading table structure. Maybe it's advantageous to store RA and
> dec in database as doubles (floats doesn't have enouch precision). They
> will require much less space and internally angles are stored in
> degrees. (See dms.h,dms.cpp) So it will be easier and simpler to
> inteface with DB.
The RA and DEC will be stored in a single field (actually, sqlite does
not have any types at all, one might put anything in a table cell -
it's a predefined size -, and should just convert it correctly when
requesting it from the database).

I was honestly thinking on a 6-byte value for each of them (since this
is how actually they are stored in ngcic.dat right now) and this would
save a _lot_ of space and even processing time. Of course, methods for
retrieving the hour, minutes, seconds will be provided so that the dev
wouldn't have to do any bitwise operations directly.

 > Also shouldn't longer and more readable names for tables be better?
> They are somewhat hard to understand.
It's easy to change them and I will let the long names be the default then.

> This is all for now. I'll think about it some more.
Thanks! I will be working this week on a query dialog (using the
KSObjectList class I wrote about on my blog) which will search through
the database. Also, I'll populate the database with more objects,
starting after another exam, on wednesday.

I'm also thinking at the way the user will update the list of objects.
A suitable method would be on downloading small chunks of data and
insert them into the database after download, step by step? I find
this as a flexible method, from all points of view - both developer,
and the user.

We'll just provide some standard ascii catalog file (similar to the
ngcic.dat) the user downloads it similar as it does with the current
extra catalogs and KStars updates in the backend the database with the
newly downloaded information.

Another method, which would operate the same as it is done with
multiple catalogs, would mean multiple prebuild databases (but this
wouldn't actually work efficient though, since the idea is to have a
central database).

Let me know what you think.

Best regards,
Victor