[Kde-pim] Akonadi db schema change needed to store search folder queryStrings

[Shaheed Haque]

Hi Will,

Is the extra storage really a concern? I suppose the pimitemtable is
probably going to have most entries by far. That seems to have a
handful of columns which might be strings (and 9 in total). Even if I
had a million records, we are talking a handful of MB.

That seems perfectly reasonable...Or have I misunderstood?

On 23 February 2012 21:12, Will Stephenson <wstephenson at kde.org> wrote:
> When using search folders in KMail (4.8) I see a lot of failed queries from
> Virtuoso on the command line.  The failed query is attempted repeatedly,
> causing extra cpu load.
>
> The reason the query fails is that the search folder stores the indexing
> database query as a string in the QString queryString attribute on Collection,
> but in our MySQL schema, all QString attributes are stored as VARBINARY(255),
> which is too short for the sparql query used by Nepomuk.
>
> As a symptom, the first mail search works, I guess because the initial,
> complete query is passed to Nepomuk without being serialized to the database
> and restored in truncated form, but subsequent searches fail because the first
> search is repeated using the broken query.
>
> Changing the field length of CollectionTable.queryStrings fixes the problem,
> done by manually running "alter table collectiontable change queryString
> queryString varbinary(1024)" in akonadiconsole.
>
> Now I've tried to fix the root problem in the database schema code in
> akonadi/server/src/storage, but if I increase the field size for QString for
> VARBINARY above 255 in dbinitializer_p.cpp, this requires an additional byte
> per field of type QString across the entire database [1] This would be a good
> few more bytes in the database overall </understatement>.
>
> I also tried to add a new data type LongQString to the schema definition
> files, that is mapped to VARBINARY(1024), but this fails because the generated
> entities.* files use the literal type attribute of the column as the c++ data
> type; there is currently no scope to map a symbolic type to an actual type.
> There is a "sqltype" attribute defined in the entities schema but this is
> unused, presumably because this was too exact in the face of different
> databases' SQL dialects.
>
> Any better suggestions how to make room for the whole query string?
>
> Will
>
> [1] http://dev.mysql.com/doc/refman/5.6/en/char.html and following section
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/