https://bugs.kde.org/show_bug.cgi?id=127321Marcel Wiesweg <
[hidden email]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email]
--- Comment #10 from Marcel Wiesweg <marcel wiesweg gmx de> 2009-07-18 14:33:21 ---
Loading SQL from an XML file sounds like a good solution to me. It allows to
decouple the SQL queries from C++ code, and, as I understand, no need to format
SQL in C++. Great so far.
My questions and comments:
1) I would recommend you to work in an SVN branch, unless you are using local
Git already. A pity KDE has not yet moved to Git. Anyway, working in the open
is better for complex changes.
2) Text handling:
SQLite has only one type for text with no imposed length limit, so we never
thought about this For MySQL we need to choose an appropriate VARCHAR or TEXT
value for the expected and allows length of each text field.
We must make sure that UTF8 and appropriate collation is used everywhere.
Indexes on text fields are limited in length. I dont see a problem from this
currently, but we should keep it in mind.
3) Which version of MySQL can we expect as minimum dependency? 5.0.3?
4) There are IIRC five source files where we use SQL, this is albumdb.cpp (95%
of statements), schemaupdater.cpp (defining the schema), haariface.cpp (a few
statements), imagelister.cpp (for album listing) and imagequerybuilder
(building select clauses)
5) Config dialogs are not critical, we need that of course but getting the
backend to work has priority
6) If we have MySQL support, we will probably default to MySQL embedded,
providing full server support only as expert setting. But as I understand this
is only a matter of linking against a different library and providing the right
parameters.
7) "DB locking - only one Digikam-App should access the DB" In fact we intend a
usage scenario where multiple applications access the same DB concurrently.
Currently you can open two digikam instances on the same db with no problems.
Change messages are currently distributed over DBus, for network scenarios this
must be done over a small network protocol (no priority for now).
Table locking issues that come with real concurrent access require some
separate thinking.
8) Transactions: We use transactions in a few places, but only as an SQLite
specific optimization, not because the operation need be atomic. The only place
where a transaction shall really ensure atomicity is the schema updating.
Thanks for your work so far!
--
Configure bugmail:
https://bugs.kde.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
