KDb/Archives/libCalligraDB: Difference between revisions
Appearance
No edit summary |
m Jstaniek moved page Kexi/KexiDB/libCalligraDB to KDb/Archives/libCalligraDB: It's an old content |
||
(3 intermediate revisions by the same user not shown) | |||
Line 8: | Line 8: | ||
** thus, calligra libs depend on the driver, i.e. depend on SQLite3 (this was the case already for Words and Kexi) | ** thus, calligra libs depend on the driver, i.e. depend on SQLite3 (this was the case already for Words and Kexi) | ||
** calligra libs depend on ICU as well for proper unicode handling (which is dependency of Qt 5 anyway) | ** calligra libs depend on ICU as well for proper unicode handling (which is dependency of Qt 5 anyway) | ||
* Predicate library, as a Qt-only component, will replace functionality of the calligradb lib | * <strike>Predicate</strike>[[KDb]] library, as a Qt-only component, will replace functionality of the calligradb lib | ||
* sqlitedump tool used for database for interactive database compacting stays in Kexi; if needed could be moved to libs/ too | * sqlitedump tool used for database for interactive database compacting stays in Kexi; if needed could be moved to libs/ too | ||
* a few functions from libkexiutils moved to libcalligradb, so libkexiutils is not dependency | * a few functions from libkexiutils moved to libcalligradb, so libkexiutils is not dependency | ||
Line 18: | Line 18: | ||
**with support from jstaniek | **with support from jstaniek | ||
**target version: 2.6 | **target version: 2.6 | ||
*port the biblio db storage to | *port the biblio db storage to <strike>Predicate</strike>[[KDb]] (by who?) | ||
**with support from jstaniek | **with support from jstaniek | ||
**target version: 3.0 | **target version: 3.0 | ||
Line 35: | Line 35: | ||
*cons and questions: | *cons and questions: | ||
**size of libKexiDB as dependency (Biblio already uses SQLite3, which is the biggest dependency compared to either QtSQL or KexiDB anyway) | **size of libKexiDB as dependency (Biblio already uses SQLite3, which is the biggest dependency compared to either QtSQL or KexiDB anyway) | ||
**we're moving to | **we're moving to <strike>Predicate</strike>[[KDb]] in Kexi (but that would happen no earlier than in 3.0, realistically in 3.1 or 3.2), so KexiDB is here for the transition period | ||
**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) | **are the APIs stable? (yes, most changes happen in <strike>Predicate</strike>[[KDb]], 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/) | **Words cannot depend on Kexi (it wouldn't, relevant parts of KexiDB should be moved to calligra/libs/) | ||
Line 53: | Line 53: | ||
***missing bits of the API needed by Biblio can be added (since there's no BC/SC requirement in KexiDB) | ***missing bits of the API needed by Biblio can be added (since there's no BC/SC requirement in KexiDB) | ||
**jstaniek offers support for smitpatel in KexiDB use | **jstaniek offers support for smitpatel in KexiDB use | ||
**jstaniek offers support for porting to Predicate when | **jstaniek offers support for porting to <strike>Predicate</strike>[[KDb]] when it arrives | ||
**jstaniek offers maintaining the libcalligradb for Qt 5.0 | **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 | **jstaniek proposes to keep KexiDB namespace in libcalligradb however since it defines API which is heavily used in Kexi (3200+ times); after moving to <strike>Predicate</strike>[[KDb]] it won't be a problem | ||
**all devs want to avoid changes of the db format so the current QtSQL-based code even if released, will be marked as experimental, before moving to KexiDB | **all devs want to avoid changes of the db format so the current QtSQL-based code even if released, will be marked as experimental, before moving to KexiDB |
Latest revision as of 18:05, 6 April 2023
The Task: Move core parts of KexiDB lib from kexi/kexidb to calligra/libs/db (libcalligradb) for reuse by Words' Bibliographic Database module and possibly other places in Calligra.
Status: in master (2.6) since 2012-07-11
Detailed changes:
- GUI- or Kexi-related bits such as validators are still in Kexi
- Only the SQLite3 driver is moved to libcalligradb, others stay within Kexi
- thus, calligra libs depend on the driver, i.e. depend on SQLite3 (this was the case already for Words and Kexi)
- calligra libs depend on ICU as well for proper unicode handling (which is dependency of Qt 5 anyway)
PredicateKDb library, as a Qt-only component, will replace functionality of the calligradb lib- sqlitedump tool used for database for interactive database compacting stays in Kexi; if needed could be moved to libs/ too
- a few functions from libkexiutils moved to libcalligradb, so libkexiutils is not dependency
- for simplicity/API stability, namespace stays as KexiDB
- README.PACKAGERS file updated
Plans:
- port the biblio db storage from plain QtSQL to libcaligradb (smitpatel)
- with support from jstaniek
- target version: 2.6
- port the biblio db storage to
PredicateKDb (by who?)- with support from jstaniek
- target version: 3.0
Minutes from IRC meeting
- 2012-07-03
- requested by jstaniek
- attended by boemann, jstaniek, smitpatel
- 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' family of templates for data re-use and manipulation
- KexiDB has database and table creation API, hides SQL complexity, QtSQL does not (what may result in code complexity in Words)
- cons and questions:
- size of libKexiDB as dependency (Biblio already uses SQLite3, which is the biggest dependency compared to either QtSQL or KexiDB anyway)
- we're moving to
PredicateKDb in Kexi (but that would happen no earlier than in 3.0, realistically in 3.1 or 3.2), so KexiDB is here for the transition period - are the APIs stable? (yes, most changes happen in
PredicateKDb, 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
- According to plans, 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, avoid extra work, and avoid two Biblio products.
- For now Kexi lacks templates that are real world and integrated with other Calligra apps. The Biblio initiative helps here.
- current state: smitpatel delivered QtSQL-based code for Biblio (within GSoC 2012), jstaniek thinks it has bits (db and table creation) already handled in KexiDB
- final agreement has been reached: KexiDB adoption in Biblio
- smitpatel already studied kexi/tests/newapi sample code and claims it looks pretty straight forward for use in Biblio
- Biblio can be still kept small enough after using with KexiDB, in fact codebase size of Biblio will decrease
- Kexi is not exposed to Words' users in any way; conversely - users may find the connection in Kexi if they decide
- jstaniek offers to move relevant part of KexiDB to calligra/libs/ ASAP
- the library renames to calligradb and the dir is calligra/libs/db/ (to avoid references to Kexi)
- missing bits of the API needed by Biblio can be added (since there's no BC/SC requirement in KexiDB)
- jstaniek offers support for smitpatel in KexiDB use
- jstaniek offers support for porting to
PredicateKDb when it 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
PredicateKDb it won't be a problem - all devs want to avoid changes of the db format so the current QtSQL-based code even if released, will be marked as experimental, before moving to KexiDB