r15094 - gnucash/branches/gda-dev - Initial commit of initial gda backend framework. See GDA_STATUS.

[Derek Atkins]

Quoting Phil Longstaff <plongstaff at rogers.com>:

> Question: A user updates to GC 2.2 (or whatever rev has the new backend)
> and opens his XML file.  He then saves the file using the Save button.
> Is it saved as SQLite?  Does the need for the Save button disappear
> because he runs from then on with the GDA backend?  Or, does he
> specifically need to Save As to convert to SQLite?

This is still an open question.  There are multiple ways to consider
handling this.  One way is to do as you suggest; if you open an XML
file it stays as an XML file, but if you create a new file it's SQLite.
In this approach users much manually convert from XML to SQLite via Save-As.
In another approach GnuCash would automatically upgrade a user from XML
to SQLite..

I don't know the right answer here.  and I dont think we need to answer
this yet, either.

>> > BTW, the file UI is built around files.  Save As, for example, doesn't
>> > allow me to save as gda://gnucash.
>>
>> This is a bug that we need to fix.
>
> Is there a bug logged for it?  If not, I'll log one.

I think there is.  I haven't looked.

> I tried merging.  If I load a commodity from the db (note that I need to
> use memcpy to stamp the guid because there is no
> gnc_commodity_set_guid(), qof_instance_set_guid() or
> qof_entity_set_guid()).  gnc_commodity_table_add_commodity().

I beg to differ:

void
xaccAccountSetGUID (Account *acc, const GUID *guid)
{
  if (!acc || !guid) return;

  /* XXX this looks fishy and weird to me ... */
  PINFO("acct=%p", acc);
  xaccAccountBeginEdit (acc);
  qof_entity_set_guid (&acc->inst.entity, guid);
  qof_instance_set_dirty(&acc->inst);
  xaccAccountCommitEdit (acc);
}

So, there IS a qof_entity_set_guid().  I suspect it's in a -p.h file,
but it exists.  You'll need to use it for all your load functions anyways.

> gnc_commodity_table_insert_commodity() will very nicely see if a
> commodity with the same namespace/mnemonic pair exist and copy the new
> one over the old one.  However, even if it copies over the guid, it
> doesn't rehash the commodity in the qof_collection, so the commodity
> can't be retrieved by the guid in the db.

Eh?  qof_entity_set_guid() should rehash the object in the entity table.

> What I'm implementing for now is a scheme to translate between
> namespace/mnemonic pairs and guids in the db.  If a row in the db (e.g.
> account table) has a certain commodity guid, I look for that guid in the
> db commodity table and get namespace/mnemonic.  I then use
> gnc_commodity_table_lookup() to find the commodity with that
> namespace/mnemonic pair, and use that gnc_commodity for
> xaccAccountSetCommodity().  If I need to commit a gnc_commodity, I get
> its namespace/mnemonic pair, find the db commodity with those values
> (during the begin_edit), and then update that row during the
> commit_edit().  This maintains all db guid references and allows the
> user to update namespace and/or mnemonic for any commodity.
>
> This is all kind of ugly, but my preference right now is to get a gda
> backend that works.  Later, commodity handling can be cleaned up.

Seriously, don't do all this extra work when you don't need to!  Just
use the GUID and qof_entity_set_guid()

>> I still believe that all db fields can be handled via a mapping.  You
>> just might need to add additional handling for certain QOF types...
>> In particular QOF Types that are compsite objects are referenced by ID
>> so you would just need a special handler.
>
> I have a simple mapper between columns and local variables which isn't
> quite how I want it, but is working.

Oh?  I didn't notice that in the code you committed.  Perhaps I should
wait for your next commit.

> The problem with the account parent example is that there is no way to
> set account B as the parent of account A.  Instead, you need to set
> account A as a child of account B.

I don't see the problem here.  The parent->child relationship is only
necessary in RAM.  You can build that one-to-many relationship from
the many one-to-one relationships of child->parent.

> One issue I thought of today: The idea of mapping all db fields is made
> more complex by gnc_numeric.  Currently, I store the num and denom as 2
> fields.  This knowledge is hidden in the code which handles the
> mappings.  However, I may need a 3rd field which will be a real with the
> value of the gnc_numeric.  Otherwise, num and denom will not be too
> useful if I need comparisons (e.g. find all splits with a value >
> $3.69).  Even a test for equality is difficult, because 10/100 ==
> 100/1000 but how I would determine this just using num and denom values
> is hard.  An alternative is to see what capabilities different SQL
> engines have.  Can I ask for SELECT * FROM split WHERE
> (value_num/value_denom > 3.69)?

That's a good question..   Each split has two gnc_numerics, an amount
and a value.  Each amount has a known denominator, based on the account
commodity_scu.  Each value has a known demoninator as well (but I don't
recall how that is chosen -- probably the transaction currency scu).  The
PG backend only stores the numerator, because the denominitor is always
understood from the context of the data.

But this DOES make life more difficult for queries by amount (or value)
because you need to somehow compute the denominator...   So I'm not really
sure what the right solution is, here.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available