Derek Atkins wrote:
>
> I admit that I don't know very much about DBMS systems. Are columns
> in a table labeled? And can you arbitrarily add a new column to an
> existing table
Yes, and yes.
While it is possible to access SQL data in a position dependant manner,
it is considered bad pract
Rob Browning wrote:
>
> it's also possible
> that when we move to SQL, that we might drop the kvp_frames
> altogether. That's something we'll have to discuss. One of the
> reasons for implementing them was that it made adding new fields when
> we needed them much easier, but it's my impression
Derek Atkins wrote:
>
> Well, using MySQL or PostgreSQL is just one part of it. It's a
> storage mechanism, but you still need to create the data formats that
> are stored. You still need to define the transaction objects or split
> objects or whatever that get stored in the database.
Well,
Patrick Spinler <[EMAIL PROTECTED]> writes:
> Derek Atkins wrote:
> >
> > Well, using MySQL or PostgreSQL is just one part of it. It's a
> > storage mechanism, but you still need to create the data formats that
> > are stored. You still need to define the transaction objects or split
> > objec
Al Snell <[EMAIL PROTECTED]> writes:
> Storing tree structures in SQL is hairy. Very hairy. Sufficiently so that
> it may be worthwhile storing the kvp tree for an object in a binary format
> in a BLOB field.
Well, I definitely appreciate your suggestions, but it's also possible
that when we mov
On 7 Dec 2000, Derek Atkins wrote:
> I admit that I don't know very much about DBMS systems. Are columns
> in a table labeled? And can you arbitrarily add a new column to an
> existing table (I suppose you could create a new table with the
> existing column information and add the new column, t
Derek Atkins <[EMAIL PROTECTED]> writes:
> Besides, if you compress the data, you lose random-access into
> the file ;)
We never have, and probably never will use that, so it's not relevant
IMO.
> Seriously, I'm not against having XML import/export, but I don't
> think it's a reasonable primary
On Thu, Dec 07, 2000 at 05:44:15PM -0500, Derek Atkins wrote:
> I admit that I don't know very much about DBMS systems. Are columns
> in a table labeled? And can you arbitrarily add a new column to an
> existing table (I suppose you could create a new table with the
> existing column informatio
I fall into the category of "wanting-to-help-but-lousy-at-C-and-scheme".
Your idea is a good one. Python is about the only language i'm
worth anything in. I will consider it for a few weeks. December
is looking pretty hopeless, workload-wise.
Mike Sabin
On Thu, Dec 07, 2000 at 05:41:43PM +110
Derek Atkins <[EMAIL PROTECTED]> writes:
> > If you are worried about load times and memory usage, we should consider
> > using a SAX interface to read in the XML. See this link for tradeoffs:
> > http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html
>
> Unfortunately the problem isn't just a
Christian Stimming writes:
> Hi,
>
> I recently discovered that all amounts in, say, the Profit and Loss Report
> are positive. Somehow all minus signs disappeared... and this happens in
> the function
>
> DxaccPrintAmount (double dval, GNCPrintAmountInfo info)
>
> by calling
>
> val =
On Thu, Dec 07, 2000 at 06:36:58PM -0500, Derek Atkins wrote:
> So the question is: are these data files meant as a storage backend
> for GnuCash, or are they meant for users to interface to directly? I
> think some people here are in the latter camp, while I am firmly in
> the former.
Both. On
I disagree.
Now, I may very well be talking out my butt here, since I've never
looked at XML closely, but my understanding is that one of the key
aspects of XML is that there's a tagged description of the data format
in the data itself, yes ? That is, XML always includes the meta data
along w
> > Also, if you do decide to try and whip something up, make sure you're
> > aware that we use kvp_frames now, in various places, so you will have
> > to be able to accomodate items with arbitrarily deep, recursive
> > key/value trees.
[...]
> > Of course you're welcome to, but why would you wast
Patrick Spinler <[EMAIL PROTECTED]> writes:
> I disagree.
>
> Now, I may very well be talking out my butt here, since I've never
> looked at XML closely, but my understanding is that one of the key
> aspects of XML is that there's a tagged description of the data format
> in the data itself, y
Rob Browning <[EMAIL PROTECTED]> writes:
> I think the synergy here is that people think that if you use XML,
> it's more likely that there will be tools that will be availble to
> allow you to manipulate your data outside the app. This is in fact
> true. Writing a parser/transformer to do some
Tyson Dowd <[EMAIL PROTECTED]> writes:
> On 06-Dec-2000, Derek Atkins <[EMAIL PROTECTED]> wrote:
> > Nobody is suggesting going back to the old binary format. I'm
> > certainly not. I *AM*, however, suggesting a NEW binary format.
>
> Any new binary format will have to be at least as extensibl
Hi,
I just took a look at the tax code documentation. This looks like it
was copied from somewhere. (specifically,
doc/html/C/xacc-txf-categories.html)
This is great stuff, but are we violating any copyrights by copying
this stuff? Last thing I want is to have Intuit try to shut us down
becau
Well, this information did come from a file provided by Quicken 2000, but
I believe the IRS and the tax code is the original source, as all this
does is document what is supposed to go on particular lines of particular
tax forms. Whether that is sufficient to cover us, I couldn't say.
I contacte
Christopher Browne <[EMAIL PROTECTED]> writes:
> XML has the merit of being easily serialized; it wouldn't be too
> difficult to use it for THAT purpose, and using other formats that are
> isomorphic to it for more direct access.
Lots of formats can be easily serialized. So can ASN.1. So can
X
Patrick Spinler <[EMAIL PROTECTED]> writes:
> This is the true reason why all the major unix subsystems do their
> configurations in ASCII flat files. Think about apache, for instance,
> or even worse, sendmail. That's one hellish config file, especially
> since it has to be parsed on startup _
Derek Atkins <[EMAIL PROTECTED]> writes:
> Honestly, I think this is a red herring. I'm not at all convinced
> that if said tools did exist they would at all be useful. Sure, you
> have a tagged data tree, but you have to know what the tags mean in
> order to do anything with them.
Well, for m
Bill, you wanted some information about ROI calculation.
All this stuff is all archived in the ML - read the thread starting
at this URL:
http://gnucash.org/gnucash-devel/June-2000/msg00409.php3
This calculations are slightly nontrivial, so sharing them with
gnumeric if possible may not be a b
Derek Atkins <[EMAIL PROTECTED]> writes:
> You're a developer. You don't count.
When I wasn't a developer, I still cared. And if you poke through the
gnucash logs over the past few years, I think you'll find I'm not
alone, but again, we obviously have different experiences here.
The 50MB of
But this is just the same as:
account_tree = load_file_version_1(filename);
save_file_version_2(filename2, account_tree);
You're not making an extensible format, you're changing the format
of the data.
-derek
Patrick Spinler <[EMAIL PROTECTED]> writes:
> Ayup - snipped from th
Rob Browning <[EMAIL PROTECTED]> writes:
> Derek Atkins <[EMAIL PROTECTED]> writes:
>
> > Honestly, I think this is a red herring. I'm not at all convinced
> > that if said tools did exist they would at all be useful. Sure, you
> > have a tagged data tree, but you have to know what the tags me
Mike Sabin writes:
> I fall into the category of "wanting-to-help-but-lousy-at-C-and-scheme".
> Your idea is a good one. Python is about the only language i'm
> worth anything in. I will consider it for a few weeks. December
> is looking pretty hopeless, workload-wise.
>
If you get a chan
27 matches
Mail list logo
