GDA save missing records

Keith Bellairs keith at
Mon Feb 18 11:43:19 EST 2008

Speaking as a user and not someone busting his butt on this, I hate the idea
of "unlimited" everything when we go to a DB. Most of our databases have a
mechanism (BLOB/CLOB) to store really big things, usually at the cost of
indexing or searching (other than with special hacks -- Oracle Text, for

gnc is not, and should not be, a doc mgmt system. I want fast, fast
retrieval and summarization. Having a place to store a reference to a doc is
a great idea; plugging up the data with the docs, not so much.

Of course, it is unforgiveable to just drop rows. Even silently truncating
data is pretty dubious. Don't know Postgres and Mysql; can't we throw an
exception so we have a chance to do the right thing (what the user needs)?

I'd ask the developers to pick some reasonable size for each column. Then
publish the schema. Granted this is a big change from the unlimited
everything, but it seems necessary. If I don't like your column size, I
should be able to ALTER TABLE and set my own favorites, so please do not
hard-code the column sizes into the code.

Keith, Guelph

On Feb 18, 2008 5:45 AM, Graham Leggett <minfrin at> wrote:

> Mark Johnson wrote:
> >> Do we really want "unlimited"?  I've alluded to this question in the
> >> past, but I don't know if there's been a definitive answer.
> Speaking for myself, I really want unlimited.
> As the accounting system is most often the system data is sent to,
> rather than originated from, it would cause all sorts of hassles if it
> turns out that the description on a transaction was arbitrarily
> truncated, or worse - the transaction was arbitrary ignored or dropped.
> I typically cut and paste full text strings from suppliers into invoice
> descriptions, and my suppliers are not limited by length, nor are their
> under any obligation to shorten their product descriptions if it causes
> hassles for me.
> This is a bit like the "640k is big enough for everybody" story, it
> isn't. :(
> Regards,
> Graham
> --
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list