[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-edu-devel
Subject: Re: [Kstars-devel] Replacing file-system by database in KStars
From: Vijay Dhameliya <vijay.atwork13 () gmail ! com>
Date: 2014-01-29 8:47:06
Message-ID: CAH-KMQjuFH6wZjNsvGhcCBz4an6ADEFOd8nQVm-7gR6XoNuURA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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@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@kde.org
>>> https://mail.kde.org/mailman/listinfo/kstars-devel
>>>
>>
>>
>> _______________________________________________
>> kde-edu mailing list
>> kde-edu@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@mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>I agree with Macro. Storing l<span \
style="font-family:arial,sans-serif;font-size:13px">ogs, notes and downloaded images \
in database is better idea for now. :)</span></div><div><span \
style="font-family:arial,sans-serif;font-size:13px"><br> </span></div><div><span \
style="font-family:arial,sans-serif;font-size:13px">Thanks</span></div><div><span \
style="font-family:arial,sans-serif;font-size:13px">Vijay</span></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote"> On Wed, Jan 29, 2014 at 1:53 \
PM, Marco Calignano <span dir="ltr"><<a href="mailto:marco.calignano@gmail.com" \
target="_blank">marco.calignano@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr">Hi,<div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><div>Cheers</div><span class="HOEnZb"><font \
color="#888888"><div>Marco</div><div><br></div></font></span></div><div \
class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jan \
29, 2014 at 3:21 AM, Vijay Dhameliya <span dir="ltr"><<a \
href="mailto:vijay.atwork13@gmail.com" \
target="_blank">vijay.atwork13@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi \
Albert,<div><br></div><div>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.</div>
<div><br></div><div>And if we have database system in KStars then maintaining \
user's logs and storing downloaded images will become more reliable and \
systematic.</div><div><br></div><div>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. \
</div>
<div><br></div><div>Regards,</div><div>Vijay</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Jan 29, 2014 \
at 2:24 AM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" \
target="_blank">aacid@kde.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div><div>El Dimarts, 28 de gener de 2014, a les \
08:22:08, Vijay Dhameliya va escriure:<br> <div><div>> Hi guys,<br>
><br>
> Currently when KStars is launched, it reads data corresponding to different<br>
> Skyobject from respective file in loaddata() methods. And I have tracked<br>
> out all the classes where we are loading data by reading file.<br>
><br>
> I researched bit on the topic and I found that loading data from database<br>
> is always much better option then doing same from file.<br>
><br>
> If we replace file system with QSql following are the Pros:<br>
><br>
> 1) We will not have to ship so many files with Kstars<br>
> 2) Loading from database is quicker than doing same from file<br>
> 3) Code for load methods will be reduced in size<br>
><br>
> Cons:<br>
> 1) I will have to move all data from files into database by temporary<br>
> methods<br>
><br>
> So I am planning to start coding to replace file system by database on my<br>
> local branch.<br>
><br>
> Can you please give your views and suggestion regarding the same ? I am<br>
> sure that It will be very helpful to me. :)<br>
<br>
</div></div>I'm not a KStars devel, but I don't really see any benefit in \
having stuff<br>
*shipped* as a SQL database, it'll be harder to maintain, to edit, to \
interact<br> with (i.e. extract text for i18n).<br>
<br>
From a end user point of view, is the current loading code that slow? Because<br>
if we are speaking of a 200ms vs 100ms change I don't see the need in redoing<br>
all the code with the bugs it may introduce.<br>
<br>
Cheers,<br>
Albert<br>
<br>
><br>
> Regards,<br>
> Vijay Dhameliya<br>
<br>
_______________________________________________<br></div></div>
Kstars-devel mailing list<br>
<a href="mailto:Kstars-devel@kde.org" target="_blank">Kstars-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kstars-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kstars-devel</a><br> \
</blockquote></div><br></div> <br></div></div><div \
class="im">_______________________________________________<br> kde-edu mailing \
list<br> <a href="mailto:kde-edu@mail.kde.org" \
target="_blank">kde-edu@mail.kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/kde-edu" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-edu</a><br> \
<br></div></blockquote></div><div class="im"><br><br clear="all"><div><br></div>-- \
<br><div>Life is short, so learn from your mistakes </div><div>And stand behind, the \
choices that you make </div><div><br></div><div>Face each day with both eyes open \
wide <br>
</div><div>And try to give don't keep it all inside </div><div><br></div><div> \
Dream Theater</div><div><br></div> </div></div>
<br>_______________________________________________<br>
kde-edu mailing list<br>
<a href="mailto:kde-edu@mail.kde.org">kde-edu@mail.kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-edu" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-edu</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic