"dp" == Dave Peticolas [EMAIL PROTECTED] writes:
dp Ok, I guess postgres's 'text' field (arbitrary length text) isn't very
dp common. That is too bad; I dislike putting limits on user-entered text
dp fields.
No, but I think Oracle has a "LONG" type which is similar; perhaps it
is
On Wed, Dec 13, 2000 at 10:02:35PM -0500, Roland Roberts wrote:
"dm" == David Merrill [EMAIL PROTECTED] writes:
dm On Wed, Dec 13, 2000 at 06:41:34PM -0800, Dave Peticolas wrote:
David Merrill writes:
On Thu, Dec 14, 2000 at 12:08:24PM +1000, Phillip Shelton wrote:
On Thu, Dec 14, 2000 at 12:11:35PM -0600, Bill Gribble wrote:
On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
Well this is a good time. As soon as I understand how they work
together I'll see how it might be achieved in the db.
It probably won't happen before you are
Phillip J Shelton writes:
David Merrill wrote:
I am very sorry. I seem to have managed to badly mis-represent the data
structures to every one. It appears that there are two ideas of what each na
means.
Could someone who knows please help me to understand how the data structures
David Merrill writes:
On Thu, Dec 14, 2000 at 12:11:35PM -0600, Bill Gribble wrote:
On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
Well this is a good time. As soon as I understand how they work
together I'll see how it might be achieved in the db.
It probably won't
On Thu, Dec 14, 2000 at 03:46:01PM -0800, Dave Peticolas wrote:
That's definitely a good approach to take.
Absolutely.
Okay, so I'm preaching to the choir. :-)
I'm used to working with incompetents. I do windows development
during the day quite a bit, although I also do the back end DB
"da" == Derek Atkins [EMAIL PROTECTED] writes:
da Locking is a challenging thing. You can't just depend on the
da filestore to lock data; what happens if you have something
da like looks like this:
[...]
da What do you do? Presumably the DB can serialize (lock)
da
I have started reworking the tax documentation. My current procedure
is to search the IRS documentation for each form/schedule and to use their
verbiage as closely as possible. I am removing any references to
particular years and dollar amounts, so we won't have to update these
every year.
This
On 13-Dec-00, 18:50 (CST), Derek Atkins [EMAIL PROTECTED] wrote:
Steve Greenland [EMAIL PROTECTED] writes:
WRT to over the wire encryption, I'd suggest looking into ssh port
tunneling. That would let those who need it use something that is well
tested and maintained, and those who don't
On Thu, Dec 14, 2000 at 03:02:08PM -0800, Dave Peticolas wrote:
David Merrill writes:
On Thu, Dec 14, 2000 at 12:11:35PM -0600, Bill Gribble wrote:
On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
Well this is a good time. As soon as I understand how they work
together
David Merrill wrote:
You can't avoid having a limit on text fields, but you can make them
very large.
The only way to get "unlimited" text fields (or a reasonable
approximation of them) is if we're willing to sacrifice database engine
portability and probable some performance at this stage
On Thu, Dec 14, 2000 at 09:57:38AM -0600, Bill Gribble wrote:
On Thu, Dec 14, 2000 at 09:27:07AM -0500, David Merrill wrote:
So currency means the unit of measure, e.g., 'USD'? But only world
currencies, not anything else (bonds, whatever)? Because they always
go in as securities.
We
-Original Message-
A related issue... Suppose you have an account with a _scu
of 100, and
the user enters a transaction with an amount that requires it to be
bumped up to 1000. (They enter 1.001). We would then bump
the damount
to 1000 and record the value as 1001? Other
Dave Peticolas [EMAIL PROTECTED] writes:
I'm not sure why it's there -- I can build fine and I installed
g-wrap in /usr.
It's there beacuse that's where I install g-wrap, but it does need to
be generalized. It needs to encode the g-wrap module dir, which is
available via g-wrap-config. We
On Wed, Dec 13, 2000 at 11:32:21PM -0800, Dave Peticolas wrote:
security: units of what is currently called 'damount' in splits
that belong to this account
currency: units of 'value' in splits that belong to this account
Neither currency or security should be stored as
I said I would work on the database schema today, but my partner and I
decided it was time to put our tree up, before Yule was past. :-)
So no schema. I'll try to do some work on it tomorrow night.
SLACKER!!
So, where were you two Sunday? Missed ya at Blake's Astral Boot
On Thu, Dec 14, 2000 at 12:47:08PM -0500, David Merrill wrote:
The security represents the commodity which the account is actually
measuring, and the currency represents the cash value, IF the security
is non-cash. It is used to verify we have a balanced transaction.
Right.
Can the user
On Thu, 14 Dec 2000, David Merrill wrote:
I disagree. One of the difficulties with databases is that it is much, much
harder to refactor that just about any other kind of programming.
We should make a valiant effort to establish an API and some table
structures that will stand the test of
On Thu, Dec 14, 2000 at 03:46:01PM -0800, Dave Peticolas wrote:
Mainly, I'm just giving you a heads up. I'm very happy that you are
working on this.
I want to throw in a big "me too" here. I know I can be sort of, um,
terse at times but I really appreciate the work to move gnucash to a
real
On Wed, Dec 13, 2000 at 11:37:00PM -0800, Dave Peticolas wrote:
David Merrill writes:
And, what do these quantities represent when storing a stock?
Generally, the precision with which your brokerage allows you to
buy stock. This may not always be something you can find out.
??? Still not
To store unlimited (un-indexed, but who needs to index comments?) text
objects, Oracle provides the CLOB (Character Large Objects).
I don't know for others, but at least DB2, SQL-Server support binary objects.
I remember that Oracle would not index on the arbitrary length string...
It didn't
David Merrill wrote:
security_scu currency_scu: 'scu' is Smallest Convertable (I think)
Unit, the denominator used for amounts in security/currency.
Commodities have default scu's, but accounts can override them.
For example, you might have stock in two different
"dp" == Dave Peticolas [EMAIL PROTECTED] writes:
dp Ok, I guess postgres's 'text' field (arbitrary length text) isn't very
dp common. That is too bad; I dislike putting limits on user-entered text
dp fields.
No, but I think Oracle has a "LONG" type which is similar; perhaps it
is
On Thu, Dec 14, 2000 at 01:23:55PM -0500, David Merrill wrote:
I want to implement the design cleanup along with the conversion to
a database back end. Why refactor the client twice, and why refactor
the db at all instead of doing it right the first time?
That's up to you. I just thought you
As far as I know:
- The only way to avoid a maximum length on a (text) field is to use a
binary object. These are called BLOBs, CLOBs, binary, and other things
by different database systems. Even these are often limited by the
implementation, but the limit is often large enough (typically 2K) to
David Merrill [EMAIL PROTECTED] writes:
I *still* don't think I understand how the rational numbers work when
working with stocks. An example or two would help. It seems that the
denominator value might change based on stock splits and such, for
example.
If you are dealing with real stocks,
G'day GnuCash developers,
On Tue, Dec 12, 2000 at 05:59:12PM -0800, Dave Peticolas wrote:
[snippage]
We already do online quotes, but that work is 'outsourced' to the
Finance::Quote program (available on sourceforge). It is a separate
project from GnuCash.
Yes, and I've been very bad
On Thu, Dec 14, 2000 at 09:54:44AM -0600, Patrick Spinler wrote:
David Merrill wrote:
You can't avoid having a limit on text fields, but you can make them
very large.
In short, if you plan on having updatable data, use varchar() columns,
for which most databases preallocate space in
On Mon, Dec 11, 2000 at 08:44:58AM +1000, Phillip J Shelton wrote:
This week I will start re-organising the gnumeric functions into better
function class groupings.
Is there anyone who I will need to talk to about with respect to either code
updates they have or the financial library?
For
On Thu, Dec 14, 2000 at 05:11:57PM -0500, Derek Atkins wrote:
David Merrill [EMAIL PROTECTED] writes:
I *still* don't think I understand how the rational numbers work when
working with stocks. An example or two would help. It seems that the
denominator value might change based on stock
David Merrill writes:
Okay. The _scu values are then the default values for damount for that
account. A split recorded against the account would have damount set
to the _scu value.
No, the scu values are the corresponding denominator values.
Although default, it could be modified later.
"dm" == David Merrill [EMAIL PROTECTED] writes:
dm On Wed, Dec 13, 2000 at 06:41:34PM -0800, Dave Peticolas wrote:
David Merrill writes:
On Thu, Dec 14, 2000 at 12:08:24PM +1000, Phillip Shelton wrote:
[...]
Do we need to worry about transaction_time here?
-Original Message-
"Phillip Shelton" [EMAIL PROTECTED] writes:
Therefore we should be able to store the accounts scu's in
the account
table?
I thought the scu was tied to the commodity, not an account.
Or did I misunderstand?
If any one has misunderstood anything it is
33 matches
Mail list logo
