Kexi/Integration/Bibliographic Database: Difference between revisions

From KDE Community Wiki
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
Words' Bibliographic Database - effort/code sharing with Kexi and possible integration with Kexi.
{{Note|Issue https://invent.kde.org/office/kexi/-/issues/111}}
 
[[Calligra/Bibliography|Words' Bibliographic Database]] - effort/code sharing with Kexi and possible integration with Kexi.


*[[/Discussion/|Initial discussion on IRC]]
*[[/Discussion/|Initial discussion on IRC]]
Line 8: Line 10:
*Words 2.5 used QtSql lib
*Words 2.5 used QtSql lib
*Words 2.6.0 switched to CalligraDB
*Words 2.6.0 switched to CalligraDB
*Plans for 2.6.2: fix data very inefficient way of data retrieval (O(n^2) CPU cost)
*Plans for 2.6.x: fix data very inefficient way of data retrieval (O(n^2) CPU cost)
**To do so, some code have to be moved from Kexi, as agreed with smitpatel
**To do so, some code (KexiTableViewData, KexiTableViewColumn) have to be moved from Kexi to CalligraDB, as agreed with smitpatel
**As a result, data will be cached on retrieval, allowing proper editing and filtering filtering
**As a result, data will be cached on retrieval, allowing proper editing and filtering filtering
**The data will be put into a table model (Qt Model/View) as needed by Words' GUI
**The data will be put into a table model (Qt Model/View) as needed by Words' GUI
Line 18: Line 20:
** all columns of Text type - why? e.g. year should be Integer
** all columns of Text type - why? e.g. year should be Integer
** no friendly captions set
** no friendly captions set
** no relationships, e.g. to Authors table
** no relationships, e.g. to Authors table or "Bibliography type" table
* why there is one table per db? we could keep one central database and let the users to create many tables, and then export/import them; importing is needed anyway since by design only one database is accessed by Words
* why there is one table per db? we could keep one central database and let the users to create many tables, and then export/import them; importing is needed anyway since by design only one database is accessed by Words

Latest revision as of 18:44, 4 April 2023


Words' Bibliographic Database - effort/code sharing with Kexi and possible integration with Kexi.

  • Initial discussion on IRC
  • Possibly two-way; as a start, in Words
  • CalligraDB is a lib moved in 2.6.0 from KexiDB to libs/ in order to enable reuse by Calligra apps, details at libCalligraDB
  • People involved: jstaniek (CalligraDB maintenance and adaptation for biblio), smitpatel (biblio), boemann (Words maintainer)
  • Only minimal changes have been made to KexiDB
  • Words 2.5 used QtSql lib
  • Words 2.6.0 switched to CalligraDB
  • Plans for 2.6.x: fix data very inefficient way of data retrieval (O(n^2) CPU cost)
    • To do so, some code (KexiTableViewData, KexiTableViewColumn) have to be moved from Kexi to CalligraDB, as agreed with smitpatel
    • As a result, data will be cached on retrieval, allowing proper editing and filtering filtering
    • The data will be put into a table model (Qt Model/View) as needed by Words' GUI

Issues

Following issues should be addressed:

  • bibref table design
    • all columns of Text type - why? e.g. year should be Integer
    • no friendly captions set
    • no relationships, e.g. to Authors table or "Bibliography type" table
  • why there is one table per db? we could keep one central database and let the users to create many tables, and then export/import them; importing is needed anyway since by design only one database is accessed by Words