Kexi/Integration/Bibliographic Database: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
A log ([[User:Jstaniek|Jstaniek]] 22:24, 21 June 2012 (BST)):
{{Note|Issue https://invent.kde.org/office/kexi/-/issues/111}}


<pre>
[[Calligra/Bibliography|Words' Bibliographic Database]] - effort/code sharing with Kexi and possible integration with Kexi.
[22:59] <smitpatel> We discussed about having kexidb/predicate in database UI in words.
 
[23:00] <smitpatel> is kexidb/predicate an alternative to QtSql ?
*[[/Discussion/|Initial discussion on IRC]]
[23:01] <smitpatel> I discussed implementing database UI using kexidb with gopalK but he dont agree to have kexidb dependency on words.
*Possibly two-way; as a start, in Words
[23:01] <jstaniek> it is developed with for this purpose
*CalligraDB is a lib moved in 2.6.0 from KexiDB to libs/ in order to enable reuse by Calligra apps, details at [[Kexi/KexiDB/libCalligraDB|libCalligraDB]]
[23:02] <smitpatel> ok. so kexi uses predicate instead of QtSql and its sql ddl statements ?
*People involved: jstaniek (CalligraDB maintenance and adaptation for biblio), smitpatel (biblio), boemann (Words maintainer)
[23:02] <jstaniek> well, Words has bigger dependencies than kexidb/predicate; e.g. sqlite is far bigger
*Only minimal changes have been made to KexiDB
[23:02] <jstaniek> and calligralibs is big too
*Words 2.5 used QtSql lib
[23:02] <jstaniek> words depends on calligralibs which contains at least 2 kexi components already...
*Words 2.6.0 switched to CalligraDB
[23:02] <jstaniek> koreports and koproperty
*Plans for 2.6.x: fix data very inefficient way of data retrieval (O(n^2) CPU cost)
[23:03] <jstaniek> I think the topic of dependencies could be put better:
**To do so, some code (KexiTableViewData, KexiTableViewColumn) have to be moved from Kexi to CalligraDB, as agreed with smitpatel
[23:04] <jstaniek> bibliographic database should be packaged separately (e.g. many people do not need it)
**As a result, data will be cached on retrieval, allowing proper editing and filtering filtering
[23:04] <jstaniek> then... kexidb dependency would not be a problem, right?
**The data will be put into a table model (Qt Model/View) as needed by Words' GUI
[23:04] <smitpatel> Yes. I agree.
 
[23:05] <smitpatel> so it would be better for words to have lighter dependency like predicate instead of QtSql + sqlite if bibliography database is packaged separately ?
==Issues==
[23:05] <jstaniek> feel free to share my thoughts - I'd like to see calligra consisted of real plugins, what means: plugins should be optional like in firefox
Following issues should be addressed:
[23:06] <jstaniek> You dont need database component in words if you dont use biblio feature, right?
* ''bibref'' table design
[23:07] <smitpatel> yes. it's the only part which uses QtSql
** all columns of Text type - why? e.g. year should be Integer
[23:07] <jstaniek> if bibliography database is packaged separately, bibliography  can depend on no mater how big dependency (but again - kexidb is really small one)
** no friendly captions set
[23:08] <jstaniek> if bibliography database is packaged separately - it would be the right approach I believe - then Words would be very compact as expected...
** no relationships, e.g. to Authors table or "Bibliography type" table
[23:09] <jstaniek> same goes to many features, e.g. mail merge, which is not used so frequently (we plan to base it on kexi)
* 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
[23:10] <smitpatel> can you point me to some documentation/code on how to use kexidb ?
[23:12] <jstaniek> you can run doxygen on the code...
[23:12] <jstaniek> and for example please look at calligra/kexi/tests/newapi/
[23:12] <smitpatel> ok :)
[23:13] <jstaniek> it's complete example, even with visual sample (table view - but table view requires kexi)
[23:14] <jstaniek> if you start with using kexidb and you're satisfied, I would move it to calligra libs
[23:15] <jstaniek> for now you could just compile kexi and grab the libkexidb.so
[23:15] <jstaniek> it requires libkexiutils.so for now too
[23:15] <jstaniek> but nothing more
[23:17] <jstaniek> Thus, and you save a lot of code that's needed when developing with QtSql, like db creation
[23:17] <jstaniek> and thus FOR FREE you'd open the database with kexi, now, and any future version.
[23:18] <jstaniek> I am assuming in the future integration for bibliography would be one of template databases in kexi itself - a kind of advanced biblio manager that users could customize if needed, e.g. to create reports...
[23:20] <smitpatel> bibliography module in kexi itself is a great idea. :)
[23:21] <jstaniek> yes... I'm not scientists but I regularly use bibliography in my research docs at Samsung...
[23:22] <jstaniek> regarding "so kexi uses predicate instead of QtSql and its sql ddl statements ?" - kexi uses libkexidb; libPredicate is next gen kexidb (kexidb trunded into a qt-only lib)
[23:23] <jstaniek> and yes, kexidb creates DDL statements automatically
[23:23] <jstaniek> for given database backend
</pre>

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
Retrieved from "https://community.kde.org/index.php?title=Kexi/Integration/Bibliographic_Database&oldid=96079"