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 example).
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 <[EMAIL PROTECTED]> 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
