Re: [Openledger-developer] Random jottings

[Tony F. <to...@sy...>]

On Wed, 2005-03-23 at 00:18, Klavs Klavsen wrote:
> |So if I'm using your API in a persistent environment (Gtk App, App
> |Server, whatever) I would have to create a new OpenLedger object for
> |each concurrent transaction I have running?
> 
> Yes (but usually in accounting each GUI has one user, there may be
> several computers running the same GUI - but then they'll have
> seperate objects/connections anyways, and thus performs one action at
> a time). IMHO that is better than having a connection for each
> transaction/invoice object.

So, say I'm writing a Tk based POS because I'm unhappy with the data
entry rate of a web interface. Each POS machine is making conntions
directly to the DB. Now, because customers are unpredictable creatures
and often change their mind half way through a POS transaction I create
a hold function. ie. Take the current transaction and set it aside and
start a new transaction so the clerk can help the next person in line.

Your saying that I would have to create a OpenLedger.pm object when I
put a transaction on hold?

> When searching for invoices, I was planning on returning an array of
> invoice-objects - ie. the resulting invoices. If we did that, a DB
> connection for each of them would be inevitable, and very ressource
> consuming.

That would be fine but the objects would have to be read only. And hence
wouldn't have to have a backing DB connection. When the user decides on
a particular invoice to edit, a new connection should be opened and an
new DB transaction started by re-retrieving the invoice.

Or you could just use a different (generic) ResultSet type object that
only retrieves the fields that the user requests for the search in the
fist place.

> Ofcourse one could argue, we should define some sort of result-subset
> - - but, as the user needs to be able to define which data they want
> shown from the search, a function that either retrives it all - or a
> subset, as defined in the function call will be required. So the
> result-set needs to be able to represent everything from 1 to every
> data in an invoice/transaction/item etc., and thus it is IMHO best to
> just return an array of the objects in question.

See above.

-- 
Tony Fraser
to...@sy...
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398