Review Request: use sqlite for storage

[Aaron Seigo]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5506/#review7926
-----------------------------------------------------------


the implementation looks good; my one question is regards keeping the data from different applets separate.


/trunk/KDE/kdelibs/plasma/private/storage.cpp
<http://svn.reviewboard.kde.org/r/5506/#comment8176>

    instead of an incrementing connectionId, you could also use the value of the this pointer? one less static int kicking around.



/trunk/KDE/kdelibs/plasma/private/storage.cpp
<http://svn.reviewboard.kde.org/r/5506/#comment8178>

    destination() is no longer used; with one db file used for all the storage, we end up with all the data in one db with no separation.
    
    it would make sense to me here to create a table for each destination().
    
    on applet destruction, it could drop its table (if any).
    
    on applet export, it could pull its table over to an exported db. (i imagine that Corona would use this in its export method).



/trunk/KDE/kdelibs/plasma/private/storage.cpp
<http://svn.reviewboard.kde.org/r/5506/#comment8179>

    ah, sql databases.
    
    this query will result in multiple rows with the same key, and when requested back you'll end up with a random row.
    
    to fix this, first delete the old row. or check if the old row exists and do an update instead of an insert. and no, there is no "update or insert" in sql. that's what sorted procedures are for ;P


- Aaron


On 2010-10-01 15:05:11, Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5506/
> -----------------------------------------------------------
> 
> (Updated 2010-10-01 15:05:11)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> looking at how slow kconfig as, this makes storage use sqlite (and makes some methods private, before it's too late)
> it can still use some improvements but it's basically working.
> two main concerns are:
> - is acceptable/safe to link to QtSql and assume the sqlite driver is present?
> - i would still see this as a fallback for when an akonadi version is not present (being in another process should slowdown the gui a bit less, but i could not want it in some mobile profiles)
> 
> the akonadi version is in the usual status "almost working with developer disappeared" :p
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1179394 
>   /trunk/KDE/kdelibs/plasma/datacontainer.h 1179394 
>   /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1179394 
>   /trunk/KDE/kdelibs/plasma/dataengine.cpp 1179394 
>   /trunk/KDE/kdelibs/plasma/private/datacontainer_p.h 1179394 
>   /trunk/KDE/kdelibs/plasma/private/storage.cpp 1179394 
>   /trunk/KDE/kdelibs/plasma/private/storage_p.h 1179394 
> 
> Diff: http://svn.reviewboard.kde.org/r/5506/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20101001/c6020f76/attachment-0001.htm