Re: Updated DDL for SQL backend
Josh Sled [EMAIL PROTECTED] writes:
On Fri, 2006-10-27 at 12:04 -0400, Derek Atkins wrote:
Josh Sled [EMAIL PROTECTED] writes:
There's a deeper modeling issue with SXes. We use a seperate, parallel
AccountGroup to store template transaction data, in which Accounts are
named as the string representation of the SXes GUID, and contain
Transactions with Splits which have their *real* Accounts, as well as
the credit and debit cell text formulae, in KVP frames.
I know David was working to re-model the AccountGroup...
True, though as I recall by giving Accounts self-hierarchy (rather than
with the current object + container system). So long as that's true,
then the book can contain a reference to the SX Account object graph
along side the normal Account object graph.
Either way, it becomes more of an issue in the DB, though, since it'll
be easier to write an incorrect query like {select * from accounts where
type = 'asset'} that would pick up SX accounts that aren't really part
of the normal hierarchy. As well, modifying the query to be correct
is actually a PITA, as you'd want to walk the tree to make how it's
rooted (either as the SX tree or the normal tree), and dbs generally
don't play nicely with hierarchical relationships. :/
I don't have a good solution, at present ... just bringing it up.
Probably the right thing is for SXes to just suck it up and model
template transactions seperately from the real
accounts/transactions/splits, though there's some serious downsides
there, too.
Actually, for Accounts it doesn't matter.. GnuCash always pre-loads
the full set of accounts. I think it's safe to pre-load the full set
of SX accounts, too. So we're never really performing queries for
Accounts based on AccountGroup.
However, we may want to query for Splits by AccountGroup... And
these queries are recursive through the AccountGroups.. *ponders*
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
Chris Shoemaker [EMAIL PROTECTED] writes: On Fri, Oct 27, 2006 at 09:32:42PM -0400, Derek Atkins wrote: Hey, I was just trying the business reports and found two bugs in trunk. Bug #1: [Menu] - Reports - Business - Printable Invoice It comes up without an invoice, but the report thinks it's trying to print invoice #0 instead of printing a message saying that you need to choose an invoice. Is this new or old? I see that same behavior in trunk at 14992. I don't see the behavior at 14992. I pulled out 14992 and it worked just fine for me. I pulled out 15023 and IT worked just fine, too. For kicks I pulled out 15024 and then I merged in 15026, 15032, 15034, 15042, and 15059 in order to fix a number of SWIG and build problems (those patches are all clearly okay on their own). This build failed. The problem is clearly the swigification. My current theory is that SWIG_NewPointerObj() returns '() instead of #f for NULL. All the scheme code expects to see #f for a NULL pointer, so there is a lot of constructs like: (if invoice ... ) If it's really returning '() then all of these need to be changed to: (if (and invoice (not (null? invoice))) ... ) and this change needs to be done EVERYWHERE! What a royal PitA.. I've been trying to read the SWIG docs but swig.sf.net appears to be down. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DB abstraction layer: libdbi vs libgda
Chris Shoemaker [EMAIL PROTECTED] writes: Based on the maintenance and availability status, I think libgda is the clear choice. Since they are at beta3 already, the unstable branch would be better. Phil, Here are some more reasons why I'd prefer libgda over libdbi: 1) libgda has better integration with glib. E.g. uses GValue. I would eventually like to see further use of GValue in GnuCash. 2) gnomedb has gtk+ widgets that are build on top of libgda. These may not be immediately useful for more than things like a connection manager or login dialog, but down-the-line I could see them being useful as presentation widgets. Note that gda also supports XML databases, so that for an interchange format, we *could* use it instead. AFAIK, this isn't true anymore. But, I believe it could be made true again if we really wanted it to. -chris It sounds like GDA is the way to go. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
--On October 28, 2006 11:13:32 AM -0400 Derek Atkins [EMAIL PROTECTED] wrote: My current theory is that SWIG_NewPointerObj() returns '() instead of #f for NULL. All the scheme code expects to see #f for a NULL pointer, so there is a lot of constructs like: (if invoice ... ) If it's really returning '() then all of these need to be changed to: (if (and invoice (not (null? invoice))) ... ) and this change needs to be done EVERYWHERE! What a royal PitA.. I've been trying to read the SWIG docs but swig.sf.net appears to be down. I think this is correct. There were similar problems in some of the reports and that's the explanation I got for the problem. See https://lists.gnucash.org/pipermail/gnucash-devel/2006-October/018834.html. I agree that finding and fixing all of these will be a pain. -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MIPGP key ID: BEA343A6 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GUIDs (was Re: SQL backend for GnuCash 2)
Phil Longstaff [EMAIL PROTECTED] writes: Since the connection string will be db-specific, we may want a db core built around libgda (see libgda vs libdbi e-mail) with a small add-on to handle the connection string formatting and how guid's will be handled (as well as adding db-specific indexes, stored procedures, ...). Hmm.. I dont know how that might work.. But maybe that's because I don't know GDA well enough. Well, with libgda, you can make a connection in 2 ways. The first is to call an API and pass a pre-defined dataset name (dsn) which contains the provider name, connection string, and other info needed. This predefined dsn is a section in ~/.libgda/config. The other way is to call a different API and pass the provider name and connection string. The connection strings are similar but will contain different info. An sqlite connection string should contain a file name, while a mysql or pgsql string should contain a host name, port number and database name. Sorry, what I meant was that I didn't understand what you meant by small add-on.. I don't know GDA well-enough to know what that means or how that would work. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated DDL for SQL backend
Phil Longstaff [EMAIL PROTECTED] writes: Hi Daniel, thanks. I made some modifications to fix most of the problems. I have both PostgreSQL and MySQL set up on my machine so I can test both dbs. One compatibility problem I have run into is that pgsql doesn't support BLOB as a data type (they have bytea instead). This is needed for the kvp slot binary type. I think it's safe to ignore the kvp BINARY type. I don't think it's used anywhere. It /may/ also be safe to ignore the kvp LIST type, but I'm not as sure that that's never used. I'm fairly confident, but not 100% sure. Thanks for the offer of help. I plan to concentrate on the core objects and on SQLite/MySQL. If you want to do the business objects and pgsql, then great. Cool.. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
Quoting Mike Alexander [EMAIL PROTECTED]: [snip] I think this is correct. There were similar problems in some of the reports and that's the explanation I got for the problem. See https://lists.gnucash.org/pipermail/gnucash-devel/2006-October/018834.html. I agree that finding and fixing all of these will be a pain. Yeah, Chris verified this is the problem and has a fix in place. I think we'll need someone to audit all the scheme code to look for any instance of (if ... and make sure it's still valid with the new '() as NULL-pointer construct.. Care to take a stab? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GUIDs (was Re: SQL backend for GnuCash 2)
On Sat, 2006-28-10 at 11:46 -0400, Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: Since the connection string will be db-specific, we may want a db core built around libgda (see libgda vs libdbi e-mail) with a small add-on to handle the connection string formatting and how guid's will be handled (as well as adding db-specific indexes, stored procedures, ...). Hmm.. I dont know how that might work.. But maybe that's because I don't know GDA well enough. Well, with libgda, you can make a connection in 2 ways. The first is to call an API and pass a pre-defined dataset name (dsn) which contains the provider name, connection string, and other info needed. This predefined dsn is a section in ~/.libgda/config. The other way is to call a different API and pass the provider name and connection string. The connection strings are similar but will contain different info. An sqlite connection string should contain a file name, while a mysql or pgsql string should contain a host name, port number and database name. Sorry, what I meant was that I didn't understand what you meant by small add-on.. I don't know GDA well-enough to know what that means or how that would work. Phil I haven't thought this through entirely, but these are my first thoughts. In order to specify the provider, we'll need the data URL to be sqlite://... or mysql://... or ... The current backend architecture is already plugin. Therefore, if I build a core backend built around libgda, then small wrapper backends for each sql db type, the core libgda piece can handle most of the heavy lifting, and the wrappers can adjust things as required (connection string, data type differences, ...). Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated DDL for SQL backend
Quoting Phil Longstaff [EMAIL PROTECTED]: I think it's safe to ignore the kvp BINARY type. I don't think it's used anywhere. It /may/ also be safe to ignore the kvp LIST type, but I'm not as sure that that's never used. I'm fairly confident, but not 100% sure. It may be safe to ignore them now, but do you want to keep the capability alive for future modifications? I can't think of any reason to... We could always add it in later if we need it. Re slot table: even if lists aren't used, there is still the hierarchy based on sub-frames. A row in the slot table may still need a link to its parent, and this can't be the guid which identifies the whole slot. We will need some sort of secondary key, then, to represent the links within the hierarchy of one complete slot. Each row in a complete slot would have the same guid, so that a complete slot could be deleted using delete from slots where guid='...', the top level slot would have parent = null and secondary_key = 0, and other rows in the slot would have parent = secondary_key_of_parent. Of course, if there are no lists, is there really any reason to bury a single slot value in a hierarchy? If lists are gone, sub-frames may be gone too. Nah... Think of a KVP slot like a filesystem directory tree. Each node can either be a File or a Directory. The Slot Path walks down the tree (through KVP_FRAMEs) until you get down to a file node, a KVP_VALUE of some data-type other that KVP_FRAME. Just because you don't have a KVP_VALUE of type list doesn't mean you can't (or shouldn't) have KVP_VALUE of type KVP_FRAME. However... You CAN model it as a flat table! Take a look at the existing PG Backend KVP implementation. You can model it as: text(32) object_id NOT NULL, text slot_path NOT NULL, enum(kvp_value_types) value_type, ... values You can construct (and deconstruct) a full kvp tree this way. No need to reference parents or anything like that. The slot_path would be a string like /A/B/C/D. Each / implies a KVP_FRAME with / denoting the root node. The only question with this approach is how you model an empty KVP_FRAME as a leaf-node in the tree. Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Another SCM bug in trunk
On Sat, Oct 28, 2006 at 12:14:57PM -0400, Derek Atkins wrote: Quoting Mike Alexander [EMAIL PROTECTED]: [snip] I think this is correct. There were similar problems in some of the reports and that's the explanation I got for the problem. See https://lists.gnucash.org/pipermail/gnucash-devel/2006-October/018834.html. I agree that finding and fixing all of these will be a pain. Yeah, Chris verified this is the problem and has a fix in place. I think we'll need someone to audit all the scheme code to look for any instance of (if ... and make sure it's still valid with the new '() as NULL-pointer construct.. Care to take a stab? I seem to be doing that at the moment. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated DDL for SQL backend
On Sat, 2006-28-10 at 11:43 -0400, Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: Hi Daniel, thanks. I made some modifications to fix most of the problems. I have both PostgreSQL and MySQL set up on my machine so I can test both dbs. One compatibility problem I have run into is that pgsql doesn't support BLOB as a data type (they have bytea instead). This is needed for the kvp slot binary type. I think it's safe to ignore the kvp BINARY type. I don't think it's used anywhere. It /may/ also be safe to ignore the kvp LIST type, but I'm not as sure that that's never used. I'm fairly confident, but not 100% sure. It may be safe to ignore them now, but do you want to keep the capability alive for future modifications? Re slot table: even if lists aren't used, there is still the hierarchy based on sub-frames. A row in the slot table may still need a link to its parent, and this can't be the guid which identifies the whole slot. We will need some sort of secondary key, then, to represent the links within the hierarchy of one complete slot. Each row in a complete slot would have the same guid, so that a complete slot could be deleted using delete from slots where guid='...', the top level slot would have parent = null and secondary_key = 0, and other rows in the slot would have parent = secondary_key_of_parent. Of course, if there are no lists, is there really any reason to bury a single slot value in a hierarchy? If lists are gone, sub-frames may be gone too. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Suggestion: click away splash screen
Quoting Thomas Klausner [EMAIL PROTECTED]: Hi! When amarok starts, it displays a splash screen while loading the program, just like gnucash. When I click on the splash screen, it immediately disappears. Perhaps the gnucash splash screen could react in the same way? (Currently it doesn't react in any obvious way.) Can you file an Enhancement Request in Bugzilla? http://wiki.gnucash.org/wiki/Bugzilla Send in a patch and it'll get fixed sooner ;) Thomas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated DDL for SQL backend
On Sat, 2006-28-10 at 12:55 -0400, Derek Atkins wrote: Quoting Phil Longstaff [EMAIL PROTECTED]: Re slot table: even if lists aren't used, there is still the hierarchy based on sub-frames. A row in the slot table may still need a link to its parent, and this can't be the guid which identifies the whole slot. We will need some sort of secondary key, then, to represent the links within the hierarchy of one complete slot. Each row in a complete slot would have the same guid, so that a complete slot could be deleted using delete from slots where guid='...', the top level slot would have parent = null and secondary_key = 0, and other rows in the slot would have parent = secondary_key_of_parent. Of course, if there are no lists, is there really any reason to bury a single slot value in a hierarchy? If lists are gone, sub-frames may be gone too. Nah... Think of a KVP slot like a filesystem directory tree. Each node can either be a File or a Directory. The Slot Path walks down the tree (through KVP_FRAMEs) until you get down to a file node, a KVP_VALUE of some data-type other that KVP_FRAME. Just because you don't have a KVP_VALUE of type list doesn't mean you can't (or shouldn't) have KVP_VALUE of type KVP_FRAME. Yes, but without lists, the analogy is each node being either a file or a directory which can contain at most 1 file or directory in it. I question the usefulness of all of the directory levels. However... You CAN model it as a flat table! Take a look at the existing PG Backend KVP implementation. You can model it as: text(32) object_id NOT NULL, text slot_path NOT NULL, enum(kvp_value_types) value_type, ... values You can construct (and deconstruct) a full kvp tree this way. No need to reference parents or anything like that. The slot_path would be a string like /A/B/C/D. Each / implies a KVP_FRAME with / denoting the root node. Fine, but without lists, isn't this equivalent to adding '/' to the list of chars which can be put into a KVP node name? Without lists, /A/B/C and /A/B/D are separate independent nodes. With lists, C and D are children in the list /A/B. The only question with this approach is how you model an empty KVP_FRAME as a leaf-node in the tree. Yes, this works. By adding 'empty' to the KVP type enum (at least in the DB), you can model empty KVP frames. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Updated DDL for SQL backend
Quoting Phil Longstaff [EMAIL PROTECTED]: Nah... Think of a KVP slot like a filesystem directory tree. Each node can either be a File or a Directory. The Slot Path walks down the tree (through KVP_FRAMEs) until you get down to a file node, a KVP_VALUE of some data-type other that KVP_FRAME. Just because you don't have a KVP_VALUE of type list doesn't mean you can't (or shouldn't) have KVP_VALUE of type KVP_FRAME. Yes, but without lists, the analogy is each node being either a file or a directory which can contain at most 1 file or directory in it. I question the usefulness of all of the directory levels. You're taking the no lists too literally. A KVP_VALUE of type LIST is effectively a File with Multiple data contents. It's NOT a directory. A Directory (KVP Value of type KVP_VALUE_FRAME) still contains a set of values! However... You CAN model it as a flat table! Take a look at the existing PG Backend KVP implementation. You can model it as: text(32) object_id NOT NULL, text slot_path NOT NULL, enum(kvp_value_types) value_type, ... values You can construct (and deconstruct) a full kvp tree this way. No need to reference parents or anything like that. The slot_path would be a string like /A/B/C/D. Each / implies a KVP_FRAME with / denoting the root node. Fine, but without lists, isn't this equivalent to adding '/' to the list of chars which can be put into a KVP node name? Without lists, /A/B/C and /A/B/D are separate independent nodes. With lists, C and D are children in the list /A/B. Yes and no.. You can iterate over all members of a KVP_FRAME. BUT this iteration is always done in RAM. The DB only needs to treat a full set of slots as an atomic unit. So, yes, you, as the DB Backend, can think of it this way because you're always loading and storing the full data-set atomically. In reality it's not the case, but you can ignore reality for your purposes. The only question with this approach is how you model an empty KVP_FRAME as a leaf-node in the tree. Yes, this works. By adding 'empty' to the KVP type enum (at least in the DB), you can model empty KVP frames. Okay... Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
