[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: kexilibs in kofficelibs [Was: Flakey Reports]
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-04-27 4:40:49
Message-ID: 200804270640.50034.mail () dipe ! org
[Download RAW message or body]

On Saturday 26 April 2008, Cyrille Berger wrote:
> > Read Sebastian's notes - it's exctly the same case - you put
> > color-management routines into libs, and we have data-management routines
> > named kexidb. The latter jumps out, to support libs though, so consider
> > these notes as just 'FYI' from a friendly guy :)
>
> Sebastian notes comes without explanation about why those things are
> needed.

y, sorry. I was probably overreacting at the moment I was running at a 
suggestion that I just see fail horrible :-/

So, as Jaroslaw named it already, Kexidb is data-managment and in fact also 
only a set of interfaces. Implementations are then backends like e.g. SQLite 
or MySQL.

The reaŝon why Kexi differs here so much from the other KO-apps if it comes to 
how to deal with data (not view) is, that other KO-apps are operating on one 
dataset, the kodocument's while Kexi always only operates on a part of the 
data, the records or the recordset. The reason is clear; A document has a 
limited size and it's not a problem to read it and then work with it aka keep 
the document in memory. But Kexi uses databases and there we talk about a lot 
of data. That means, that everything within Kexi does operate the whole time 
only on a subset of all the data.

Same with forms and reports; we just can't fetch everything and then display 
it but we need to go step by step. Read a record, display it, read the next 
record, ...
Just compare this with what KSpread does which is very similar here to Kexi 
(matrix/table/sheet of data to deal with). There was fantastic work done in 
the 2.0-lifetime to be able to deal with large sheets, but still... try to 
load e.g. 50k of rows (aka records) into a sheet (and 50k is still a small 
database) and KSpread eats mem, slows down and takes ages to deal with that 
data. For Kexi there is no difference if there are 2 rows, 50k of rows or 
even more cause Kexi does not need to deal with all of the data at the same 
time anyway and therefore it only reads, displays and deals with the data it 
needs.

Flake atm comes with loadOdf/saveOdf. But what we need would be 
goToFirstRecord/goToNextRecord plus functionality to know about the 
design/layout of the datastore (aka the table) to be able to know that e.g. 
column 2 is an int and therefore can be used for e.g. calculations or that 
column 3 is an image that can be fetched+displayed on demand.

Thinking again about this my prev refer to mailmerge was probably even 
incomplete since it goes also in the KoStore-way. KoStore itself does btw 
also lazy load files on demand for exactly the same reason; to load first 
everything into the mem and then operate on it, is just slow and for the case 
of databases just impossible.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]