[EMAIL PROTECTED] (Bill Gribble) writes:
> Yes, I do. Unless you have some other reason not to want to put
> purchase/sell quotes in the database, I think we should stick with
> the current plan, which is to have a unified database of "net"
> quotes and quotes from buys/sells. I don't believe sticking quotes
> in the split addresses the real problems that the quote database was
> designed to address, and it adds more layers of logic to determining
> the "balance" of a stock account and to reports that are trying to
> manipulate stock prices.
Well, putting the quote in the split means that we don't have to deal
with allocation issues, we don't have to worry about mingling
official[1] (possibly shared) information with user entered
transaction specific quotes, and we don't need *any* infrastructure to
handle callbacks on modify/delete.
Now this doesn't mean that we absolutely *shouldn't* do what we
initially discussed, but these issues did make me think the "quote in
buy/sell split" approach may have some advantages. We're probably
going to have to have more flexible splits in stock registers anyway
-- we've got to be able to handle splits and merges, for example, and
those "event splits" should probably be in-line, though I guess they
could also be in the DB, and then you would search for all events
relating to a given commodity before displaying the register for a
given date range.
In any case, the problems and complexities of having one mingled
database suggested (at least to me) that the burden of proof should be
on the more complex approach -- which at the time seemed to me to be
the unified DB approach. Though as your comments point out, how you
quantify complexity depends on your perspective. So here we are --
with an open issue that we've got to evaluate.
[ Just to clarify, in case there's been some misunderstanding. I was
proposing putting the user entered quote into the buy/sell split. I
think this probably solves the issue of what to do for actual buys
and sells. We'd also have the price DB (API) for non-split-related
quotes, and that's where all the quotes from the old "quote getter"
(and the new one) would/will go. ]
[1] i.e. say we allow the user to hook their financial stastistics up
to a CD-ROM or an on-line, live "comprehensive" database. They
probably want un-locally-tainted results for graphs, analysis,
etc., though maybe not -- worth considering, anyway IMO.
> Is it really that painful to put buy/sell prices in the database?
Am I supposed to answer that?
In point of fact, I don't really care which way we go, and I think you
know me well enough to know that difficulty in implementation isn't
usually at the top of my criteria list. I'd just like to make sure we
pick the best answer given what we know and where we think we might
be going.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
