Kexi/KexiDB: Difference between revisions

Revision as of 21:28, 3 July 2012

This page will be moved to Predicate when Kexi moves to Predicate.

idea: storage for bibliography could re-use libKexiDB instead of libQtSQL
pros:
- simplify the code
- increase code re-use - KexiDB is developed 8+ years already with reuse in mind
- make the database ($HOME/.calligra/biblio.sqlite) accesible to Kexi, so biblio db can be added to the Kexi Scientific templates for data re-use and manipulation
KexiDB has database and table creation API, QtSQL does not (code complexity)
cons:
- size of libKexiDB as dependency (Biblio already uses SQLite3, which is the biggest dependency compared to either QtSQL or KexiDB)
- we're moving to predicate (but that would happen no earlier than in 3.0, realistically in 3.1 or 3.2), so KexiDB is here for the transition
- are the APIs stable? (yes, most changes happen in Predicate, moreover KexiDB is calligra's internal API, so will be updated with the apps and the Biblio code)
- Words cannot depend on Kexi (it wouldn't, relevant parts of KexiDB should be moved to calligra/libs/)

extra points, from Kexi's perspective
- Kexi will have biblio-feature db in 3.x anyway as a template, which ideally would depend on Words too. With kexidb reuse we would avoid incompatible two databases, extra work, and two Biblio products.
- For now Kexi lacks templates that are real world and integrated with other Calligra apps.

current state: smitpatel delivered QtSQL-based code for Biblio (within GSoC 2012)

KexiDB adoption
Biblio can be still kept small enough
jstaniek offers to move relevant part of KexiDB to calligra/libs/
- the library renames to calligradb and the dir is calligra/libs/db/ (to avoid references to Kexi)
jstaniek offers support for smitpatel in development
jstaniek offers support for porting when Predicate arrives
jstaniek offers maintaining the libcalligradb for Qt 5.0
jstaniek proposes to keep KexiDB namespace in libcalligradb however since it defines API which is heavily used in Kexi (3200+ times); after moving to Predicate it won't be a problem

@@ Line 22: / Line 22: @@
 **are the APIs stable? (yes, most changes happen in Predicate, moreover KexiDB is calligra's internal API, so will be updated with the apps and the Biblio code)
 **Words cannot depend on Kexi (it wouldn't, relevant parts of KexiDB should be moved to calligra/libs/)
+*extra points, from Kexi's perspective
+**Kexi will have biblio-feature db in 3.x anyway as a template, which ideally would depend on Words too. With kexidb reuse we would avoid incompatible two databases, extra work, and two Biblio products.
+**For now Kexi lacks templates that are real world and integrated with other Calligra apps.
 *current state: smitpatel delivered QtSQL-based code for Biblio (within GSoC 2012)
@@ Line 30: / Line 34: @@
 *Biblio can be still kept small enough
 *jstaniek offers to move relevant part of KexiDB to calligra/libs/
-**the library renames to calligradb and the dir is calligra/libs/db/
+**the library renames to calligradb and the dir is calligra/libs/db/ (to avoid references to Kexi)
 *jstaniek offers support for smitpatel in development
 *jstaniek offers support for porting when Predicate arrives
+*jstaniek offers maintaining the libcalligradb for Qt 5.0
+*jstaniek proposes to keep KexiDB namespace in libcalligradb however since it defines API which is heavily used in Kexi (3200+ times); after moving to Predicate it won't be a problem