[Digikam-devel] [Bug 127321] allow use of other database backends such as postgres and mysql

[Quallenauge]

https://bugs.kde.org/show_bug.cgi?id=127321





--- Comment #16 from Quallenauge <Hamsi2k freenet de>  2009-07-22 07:25:06 ---
[KDE SVN Account]
Done. I would like to check in my changes in SVN. How should the branch named?!
(Proposal: /home/kde/branches/extragear/graphics/digikam/0.10-extdb)

[Field length]
>...paths are difficult to predict (260? No. 1024? 4096? Even longer?)
In this cases, I would use a reasonable limit for that. Better we allocate more
than lower space. (For the LONGTEXT there is an overhead of 4bytes per entry
see http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html ).

[MySQL Version]
>Best choice is to be compatible with amarok here. They say 5.0. We should pick
>any version widely available on all modern distributions, not too recent and
>not too old.
I'm fine with MySQL 5.0.

[Multi Instance DB Access]
>In AlbumDB, there are a lot of statements backend->recordChangeset(...). All these changesets
>are already broadcast as DBus signals to other digikam apps.
>They are as well exclusively used for application-internal change notification.

Okay, as I understand there are already some points which can be used for the
future network protocol. I think this should be the second or third step of our
journey to external DB access.

[Named placeholders]
>Yes, if you look at the source of the Qt MySQL driver, it supports only
>positional placeholders, no named placeholders. Same for SQLite btw, that's why
>we only use positional placeholders so far.

That make things clear...

>There are a few batch operations at performance critical points. No need for
>true batch operations here, but prepared queries should be used.
Ok, we can use the statements unmodified.

>There will be a specified number and order of expected bound values for each
>action anyway as far as I see this. So why not use positional binding?

I have some points:
1) Code is flexible. You can change the order of parameters in statement (in
case of bugfixing or optimizing a query).

2) You can add easy a additional conditions or a sub select with the used
placeholders. E.g.:
Before: SELECT * FROM table where ID=:ID
After:  SELECT * FROM table where ID=:ID AND PID=:ID

3) A DB action accept 0-n statements. When they are executed, positional
binding can not be used because the placeholders are all on a different place.
E.g:
<dbaction name="GetTableContent" mode="transaction">
  <statement mode="query">INSERT INTO table (name) VALUES (:name)</statement>
  <statement mode="query">SELECT FROM table WHERE ID=:ID</statement>
</dbaction>              

3) It doesn't add complexity, but more readable code. You have to 
    QMap<QString, QVariant> parameters;
    parameters.insert(":tagPID", parentTagID);
    parameters.insert(":tagname", name);
and give that to the sql executing method. The only side effect is a little
overhead for creating the QMap object at runtime.

BTW: I have now an implementation, which is SQL injection save. I would checkin
this as soon if I have a branch :)

[ORM]
I'm fine with sql queries.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.