[Kde-finance-apps] Query methods for Alkimia Database Class

[Thomas Baumgart]

Hi Mukesh,

on Wednesday 16 June 2010 Mukesh Gupta wrote:



> Hello Thomas ,Klass ,Fernando,Alvaro and all,
> 
> I have written some initial code of the Database class which will handle
>  all Sqlite database related operations for the alkimia Dbus service.
> The initial code contains methods for inserting and updating a record in
>  the database.
> Now i need a help regarding the possible query methods.The available fields
> are transaction id,source application name,memo,amount,status and date.
> Also tell me what are the other methods that could become a part of the
> code.

I am somewhat lost to what you are actually doing. Guess I have to go back to 
the wiki and read it again. Sorry 'bout that, but I think for my answer below 
this is not really necessary to know.

> How should the amount field be represented in database? Can we store it as
>  a string and write an alkvalue method to convert string to alkvalue. Or we
>  should store both numerator and denominator of the alkvalue as Double in
>  database.

Regarding the storage of the numbers: they have arbitrary size and precision 
which would cause some trouble if you simply use a double (which has limited 
precision). An AlkValue has a string representation which can be stored in a 
database field (varchar). The AlkValue ctor can take this string and convert 
it back to its internal representation, so there's no need to write a special 
function for that. Given that the db-field is wide enough to fit all 
characters, you will not loose and information.

The problem is, that you cannot use db functions like sum() to calculate a 
balance using that string representation. The KMyMoney implementation thus has 
two db fields, one takes the string and the other a numeric value. Fernando 
certainly knows more about that part.

In case you store the numerator and denominator as separate values in two db 
fields, you do not gain anything compared to the string representation.

Thinking of doubles and leaving long doubles aside for now, you have 64 bits 
of information where 53 are used for the mantissa which gives you 15 digits of 
precision. See http://en.wikipedia.org/wiki/Double_precision for details. 
Using a long double which is not available on all systems and not available on 
the db side, you have 80 bits with 64 used by the mantissa giving you a 19 
digit precision (http://en.wikipedia.org/wiki/Extended_precision).

Using doubles will present you some rounding problems down the line. That is 
one reason, why we want to use AlkValue for all internal math. You have been 
warned ;)

Using a "long long" (which is also not available on all systems) you have 64 
bits for the numerator and 64 bits for the denominator (this is what KMyMoney 
uses today). This gives you also 19 digits of precision.

> Sorry i cannot upload the code due to some problem with svn account.We do
> that as soon as possible.

So much for my 0.02

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
To mess up a Linux box, you need to work at it;
to mess up your Windows box, you just need to work on it.
Scott Granneman, Security Focus
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100616/c6beb77c/attachment.sig