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

[Vijay Dhameliya]

Hi,

I agree with Macro. Storing logs, notes and downloaded images in database
is better idea for now. :)

Thanks
Vijay


On Wed, Jan 29, 2014 at 1:53 PM, Marco Calignano
<marco.calignano at gmail.com>wrote:

> Hi,
>
> 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.
>
> Cheers
> Marco
>
>
>
> 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
>
>
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140129/06884f45/attachment-0001.html>