[Kstars-devel] Replacing file-system by database in KStars

Marco Calignano marco.calignano at gmail.com
Wed Jan 29 08:23:35 UTC 2014


why we do not look for an hybrid solution? For example we could leave
KStars data in file like they are, but we can offer the user a database for
hers/his logs, notes and downloaded images.
First of all this would make everyone happy, it also would solve some
problem on where to store the database (home directory, or appdata
directory) and it would offer us to see if it is worth, in term of KStars
performance to make the migration to full database.


On Wed, Jan 29, 2014 at 3:21 AM, Vijay Dhameliya
<vijay.atwork13 at gmail.com>wrote:

> Hi Albert,
> Replacing file system by database not only reduce loading time and files
> from source code but it will provide scope to feature like adding, editing,
> and removing DSOs (deep sky objects) and other similar sky-objects.
> And if we have database system in KStars then maintaining user's logs and
> storing downloaded images will become more reliable and systematic.
> And KStars allows user to add their own catalog which may contain any
> number of DSOs (i.e. raws for database or line in file). So when talking
> about such large data, loading time will be reduced significantly.
> Regards,
> Vijay
> On Wed, Jan 29, 2014 at 2:24 AM, Albert Astals Cid <aacid at kde.org> wrote:
>> El Dimarts, 28 de gener de 2014, a les 08:22:08, Vijay Dhameliya va
>> escriure:
>> > Hi guys,
>> >
>> > Currently when KStars is launched, it reads data corresponding to
>> different
>> > Skyobject from respective file in loaddata() methods. And I have tracked
>> > out all the classes where we are loading data by reading file.
>> >
>> > I researched bit on the topic and I found that loading data from
>> database
>> > is always much better option then doing same from file.
>> >
>> > If we replace file system with QSql following are the Pros:
>> >
>> > 1) We will not have to ship so many files with Kstars
>> > 2) Loading from database is quicker than doing same from file
>> > 3) Code for load methods will be reduced in size
>> >
>> > Cons:
>> > 1) I will have to move all data from files into database by temporary
>> > methods
>> >
>> > So I am planning to start coding to replace file system by database on
>> my
>> > local branch.
>> >
>> > Can you please give your views and suggestion regarding the same ? I am
>> > sure that It will be very helpful to me. :)
>> I'm not a KStars devel, but I don't really see any benefit in having stuff
>> *shipped* as a SQL database, it'll be harder to maintain, to edit, to
>> interact
>> with (i.e. extract text for i18n).
>> From a end user point of view, is the current loading code that slow?
>> Because
>> if we are speaking of a 200ms vs 100ms change I don't see the need in
>> redoing
>> all the code with the bugs it may introduce.
>> Cheers,
>>   Albert
>> >
>> > Regards,
>> > Vijay Dhameliya
>> _______________________________________________
>> Kstars-devel mailing list
>> Kstars-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kstars-devel
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu

Life is short, so learn from your mistakes
And stand behind, the choices that you make

Face each day with both eyes open wide
And try to give don't keep it all inside

                                               Dream Theater
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140129/8094c1a0/attachment.html>

More information about the kde-edu mailing list