Difference between revisions of "Kexi/KexiDB"

Line 15: Line 15:
 
**simplify the code
 
**simplify the code
 
**increase code re-use - KexiDB is developed 8+ years already with reuse in mind
 
**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
+
**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, QtSQL does not (code complexity)
+
**KexiDB has database and table creation API, hides SQL complexity, QtSQL does not (what may result in code complexity in Words)
 
*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)
+
**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 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
+
**we're moving to predicate 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 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/)
 
**Words cannot depend on Kexi (it wouldn't, relevant parts of KexiDB should be moved to calligra/libs/)
  
 
*extra points, from Kexi's perspective
 
*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.  
+
**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.
+
**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)
+
*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'''
 
*'''final agreement has been reached'''
  
*KexiDB adoption
+
*KexiDB adoption discussed
*Biblio can be still kept small enough
+
*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/
 
*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)
 
**the library renames to calligradb and the dir is calligra/libs/db/ (to avoid references to Kexi)
Line 39: Line 41:
 
*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 Predicate 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

Revision as of 21:37, 3 July 2012

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

See http://kexi-project.org/wiki/wikiview/[email protected]

libCalligraDB

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 predicate 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)
    • 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 discussed
  • 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/
    • 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
  • 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

This page was last edited on 3 July 2012, at 21:37. Content is available under Creative Commons License SA 4.0 unless otherwise noted.