Backend customisation and be->price_lookup
linux at codehelp.co.uk
Thu Sep 22 14:16:12 EDT 2005
On Thursday 22 September 2005 6:54 pm, Derek Atkins wrote:
> Um, don't you want this extension to be per-backend? E.g. the File
> Backend and the SQL Backend would want to supply different extensions,
Yes - it is designed that way - sorry if that wasn't clear. It can also be
shared between backends if that becomes appropriate (can't think why it would
be used though!)
> This way, the *number*, type and IDstring
> of all backend extensions are entirely determined by the backend in use.
i.e. it is up the backend to decide if it needs 0, 1, 2 or lots of extensions
- as well as deciding what type of extensions it needs and the IDstrings for
Each backend can have as many extensions as it needs, they can be unique to
that backend or, theoretically, shared between them.
> > qof_backend_extension_add("GNCPriceLookupID", pgendPriceFind);
> Wouldn't you need this to be per-backend?
It is - each backend provider initialises their own extension(s) in their
QofBackendProvider init function - the one that's called by
> > Alternatively, can price_lookup be dropped and a generic (QofQuery)
> > query used already?
> I don't know. The current Query mechanism might not provide the full
> requirements for the pricedb searches.. I particular the "closest in
> time" type searches don't quite work right.
> > Are there any implications for Finance::Quote?
:-) Worth checking.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050922/f82695db/attachment.bin
More information about the gnucash-devel