On Sun, 17 Dec 2000 23:11:15 EST, the world broke into rejoicing as
David Merrill <[EMAIL PROTECTED]> said:
> On Sun, Dec 17, 2000 at 05:43:57PM -0600, Rob Browning wrote:
> > Jean-David Beyer <[EMAIL PROTECTED]> writes:
> >
> > At this point, as I've said, I now tend to think that we should jus
On Sun, Dec 17, 2000 at 05:43:57PM -0600, Rob Browning wrote:
> Jean-David Beyer <[EMAIL PROTECTED]> writes:
>
> At this point, as I've said, I now tend to think that we should just
> plan to handle encryption/authentication directly by having a
> server-side gnucash daemon.
I think so, too.
>
On Sun, Dec 17, 2000 at 09:43:48PM -0600, Christopher Browne wrote:
>
> And the issue is _quite_ to the point, irrespective of anything
> having to do with MySQL.
>
> The examination of DB schema has thus far concentrated on what the
> field types need to be; that is important enough, but only g
On Sun, Dec 17, 2000 at 09:54:32PM -0500, Jean-David Beyer wrote:
> David Merrill wrote:
> >
> > On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > > Christopher Browne wrote (in part):
> > > >
> > > > This is something that is indeed appropriately generated in the "engine,"
>
On Sun, 17 Dec 2000 21:54:32 EST, the world broke into rejoicing as
Jean-David Beyer <[EMAIL PROTECTED]> said:
> David Merrill wrote:
> >
> > On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > > Christopher Browne wrote (in part):
> > > >
> > > > This is something that is inde
> -Original Message-
> Doesn't leave much to work with.
>
> > -Original Message-
> > > Your second question: what do we do about stocks that change names
> > > and/or ticker symbols? This is an issue we haven't really
> > > addressed.
> >
> > I defintely don't know enough right
Doesn't leave much to work with.
> -Original Message-
> > Your second question: what do we do about stocks that change names
> > and/or ticker symbols? This is an issue we haven't really
> > addressed.
>
> If we could associate some unique id with a given commodity, we could
> use that
[EMAIL PROTECTED] (Bill Gribble) writes:
> Accounts have pointers to gnc_commodities, not just names. If the
> problem is picking the right stock for the account, there are plenty
> of UI ways to make sure you get the right one.
Isn't there still a problem on file load? The file only stores th
[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 s
"Phillip Shelton" <[EMAIL PROTECTED]> writes:
> Accounts can have subaccounts. The subaccounts are identified by the
> parent_account_guid, which indicates the parent account.
We have also discussed the possibility that we might switch to just
having a flat account list, and then have another st
"Phillip Shelton" <[EMAIL PROTECTED]> writes:
> Then, as a lazy programmer, how much of this can we legally steal
> from other server-proxies?
Dunno, but if we go this way, all we really need is some reasonably
good server code, and I suspect that there are quite a few projects we
can beg/borrow
David Merrill wrote:
>
> On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > Christopher Browne wrote (in part):
> > >
> > > This is something that is indeed appropriately generated in the "engine,"
> > > not in the DB; the relevance to the DB is to ask whether it can use the
>
On Sun, Dec 17, 2000 at 05:21:27PM -0600, Rob Browning wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > > We need to be more specific about what we need in terms of query
> > > efficiency. It may make sense to use one storage/indexing strategy
> > > for non-text fields and a completely d
On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> Christopher Browne wrote (in part):
> >
> > This is something that is indeed appropriately generated in the "engine,"
> > not in the DB; the relevance to the DB is to ask whether it can use the
> > GUID as one of its keys, and wh
On Sun, Dec 17, 2000 at 05:04:49PM -0600, Rob Browning wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > When I looked at the code the algorithm seemed nonstandard to me,
> > and I want to make sure I use a standard GUID algorithm. It's well
> > tested and has proved itself. If Our algorit
Bill Gribble wrote:
>
> On Sun, Dec 17, 2000 at 08:38:36PM -0500, Jean-David Beyer wrote:
> > Do gnc_commodities have unique keys that identify them? E.g., does the
> > commodity
> >
> > {stock, company_name McAfee Associates, ticker MCAF, other_data}
> >
> > have as one of its keys a unique iden
On Sun, Dec 17, 2000 at 08:38:36PM -0500, Jean-David Beyer wrote:
> Do gnc_commodities have unique keys that identify them? E.g., does the
> commodity
>
> {stock, company_name McAfee Associates, ticker MCAF, other_data}
>
> have as one of its keys a unique identifier that is the same as the
> u
(Taken from David M's schema.txt)
ACCOUNT
---
account_guidchar32
parent_account_guid char32 -> account.account_guid
account_typeinteger ->
account_types.acct_type_code
account_codechar20 a mn
Christopher Browne wrote (in part):
>
> This is something that is indeed appropriately generated in the "engine,"
> not in the DB; the relevance to the DB is to ask whether it can use the
> GUID as one of its keys, and whether or not the DB supports foreign keys.
What is this "foreign key" stuff
Bill Gribble wrote (in part):
>
> On Sun, Dec 17, 2000 at 05:09:55PM -0600, Rob Browning wrote:
> > Jean-David Beyer <[EMAIL PROTECTED]> writes:
> >
> > > Whether or not you store the price database in a formal dbms or not,
> > > what would you use as the primary key for the entries?
> >
> > [.
Phillip Shelton wrote:
>
> > -Original Message-
> > This can certainly be a problem, but if the person who has the role of
> > database designer normalizes (preferably to at least 3BNF*)
> > the database
> > when designing it, the times you would want to change its basic design
> > should
On Sun, Dec 17, 2000 at 05:09:55PM -0600, Rob Browning wrote:
> Jean-David Beyer <[EMAIL PROTECTED]> writes:
>
> > Whether or not you store the price database in a formal dbms or not,
> > what would you use as the primary key for the entries?
>
> [...]
>
> Excellent points. Thank you. In ad
> -Original Message-
> David Merrill <[EMAIL PROTECTED]> writes:
> As you also suggest later in this message, the more I think about it
> and read other people's comments, unless I'm overlooking something
> obvious, having a gnc-server-proxy now seems to me inevitable. It
> provides us
> -Original Message-
> This can certainly be a problem, but if the person who has the role of
> database designer normalizes (preferably to at least 3BNF*)
> the database
> when designing it, the times you would want to change its basic design
> should be extremely few, since each table
Jean-David Beyer <[EMAIL PROTECTED]> writes:
> I just looked at it and it just showed me how much I do not know
> about double-entry bookkeeping. I am familiar with the Quicken model
> (if I may call it that), and have no predisposition to it. But the
> GnuCash model requires a different mind set
David Merrill <[EMAIL PROTECTED]> writes:
> > * design an API that's exactly what we need, regardless of the DB
> > involved, and plan to just have a server-side gnucash daemon
> > that manages the DB interface, dealing with any limitations of
> > the DB on the server-side
David Merrill <[EMAIL PROTECTED]> writes:
> > We need to be more specific about what we need in terms of query
> > efficiency. It may make sense to use one storage/indexing strategy
> > for non-text fields and a completely different one for text fields.
> > It's my opinion that having arbitraril
Jean-David Beyer <[EMAIL PROTECTED]> writes:
> Whether or not you store the price database in a formal dbms or not,
> what would you use as the primary key for the entries?
[...]
Excellent points. Thank you. In addition the stuff we were already
worried about, this seems more than enough ju
David Merrill <[EMAIL PROTECTED]> writes:
> When I looked at the code the algorithm seemed nonstandard to me,
> and I want to make sure I use a standard GUID algorithm. It's well
> tested and has proved itself. If Our algorithm is already standard,
> then I just misread it; I'm human. If it's not
On Sun, Dec 17, 2000 at 11:41:10AM -0600, Christopher Browne wrote:
> On Sun, 17 Dec 2000 10:09:04 CST, the world broke into rejoicing as
> [EMAIL PROTECTED] (Bill Gribble) said:
> > On Sat, Dec 16, 2000 at 12:05:42PM -0500, David Merrill wrote:
> > > Obviously, the current algorithm is working.
On Sun, Dec 17, 2000 at 10:18:02AM -0600, Bill Gribble wrote:
> On Sat, Dec 16, 2000 at 12:29:50PM -0500, David Merrill wrote:
> > Unfortunately, however, allowing *very* large text fields has serious
> > drawbacks in databases that it does not have in XML. You pay a price
> > in terms of storage
On Sun, 17 Dec 2000 10:09:04 CST, the world broke into rejoicing as
[EMAIL PROTECTED] (Bill Gribble) said:
> On Sat, Dec 16, 2000 at 12:05:42PM -0500, David Merrill wrote:
> > Obviously, the current algorithm is working. So there is no reason to
> > change it, but I'm doing essentially a new imp
On Sat, Dec 16, 2000 at 12:29:50PM -0500, David Merrill wrote:
> Unfortunately, however, allowing *very* large text fields has serious
> drawbacks in databases that it does not have in XML. You pay a price
> in terms of storage space and indexing, which translates to query
> execution speed. Not j
On Sat, Dec 16, 2000 at 12:05:42PM -0500, David Merrill wrote:
> Obviously, the current algorithm is working. So there is no reason to
> change it, but I'm doing essentially a new implementation of that
> code, so I want to make sure it is solid in all respects. Possibly
> postgres has a built-in
34 matches
Mail list logo
