|
|
| (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>
| |
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
