Re: GDA: Status
Phil Longstaff [EMAIL PROTECTED] writes: Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: My appologies for sounding like a broken record, but if you look at MythTV they show how to support both MySQL and PG in an automated fashion. At least I'm pretty sure they can create and update tables for both DBs. I'll take a look at MythTV. The only places I had looked at were from links on the libdbi website. We should have a plan in place at day 1 for how we'd deal with this. I DO like the MythTV model where we have a DB Schema Version number in a known table/location and then we can use that to detect whether we need updates. I recently added a version number per table. At a minimum, we would need 1 for core and 1 for business. I dont think you need a version number per table. I think it's safe enough to have a global DB Schema Version, because you're not going to be updating one table without updating the whole schema. But you're right that we might need a version number for core and another version number of business. Perhaps we just need a settings table? 4) switch gda calls to dbi calls 5) lots more. think you should be more explicit here in step two (okay, step 5). What's lots more here? I think what I want to do is create a dbi backend in the gda-dev2 tree, copy the gda code over, and just see what would be required to modify everything. That would give me a feel for the amount of effort required to switch. Do you want to do this in the gda-dev or would you like a new branch to work from? Branches are cheap. At this point, I'll work in gda-dev. Okay. I was just thinking that maybe dbi-dev would be a more appropriate name. But up to you. 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: GDA: Status
Derek Atkins wrote: to switch. Do you want to do this in the gda-dev or would you like a new branch to work from? Branches are cheap. At this point, I'll work in gda-dev. Okay. I was just thinking that maybe dbi-dev would be a more appropriate name. But up to you. What I'm actually doing is breaking out core sql-based code which uses abstract connection, statement, result and result-row objects. I'll then use this to create a gda backend, to test the concept (and code) and then a dbi backend. For the gda backend, this ends up being a split and restructure of the current code. For the dbi backend, this means reimplementing connection/statement/result/result-row in terms of dbi. You could create sql-dev if you want it to be in a more appropriately named branch. As long as I'm isolated from everyone else, I don't care. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Quoting Phil Longstaff [EMAIL PROTECTED]: Derek Atkins wrote: to switch. Do you want to do this in the gda-dev or would you like a new branch to work from? Branches are cheap. At this point, I'll work in gda-dev. Okay. I was just thinking that maybe dbi-dev would be a more appropriate name. But up to you. What I'm actually doing is breaking out core sql-based code which uses abstract connection, statement, result and result-row objects. I'll then use this to create a gda backend, to test the concept (and code) and then a dbi backend. For the gda backend, this ends up being a split and restructure of the current code. For the dbi backend, this means reimplementing connection/statement/result/result-row in terms of dbi. You could create sql-dev if you want it to be in a more appropriately named branch. As long as I'm isolated from everyone else, I don't care. This sounds like an excellent plan! I think there's just a lot of cruft in the current gda-dev branch which is why I was suggesting a new one. Like I said, branches are cheap. You have full access to SVN so you could create a new branch yourself: svn cp .../trunk .../branches/sql-dev 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: GDA: Status
Phil Longstaff [EMAIL PROTECTED] writes: Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? I took a look at a few projects using libdbi. They seem to have some external mechanism (script) to create the db, and they also seem to have more of a permanent database idea (e.g. a reference database, a library contents database). MythTV has support for both MySQL and PG and does database creation and upgrades in both underlying DBs. So there's clearly a way to have mostly-common SQL. Well, as long as queries and data modification stick to standard sql, gc could be ok. Note that there are some things which, whether standard sql or not, I would like to use if available e.g. the ability to insert multiple rows at a time (for slots) which is not supported by sqlite. If it's not supported by SQLite then how do you do it? Or are you saying that GDA is smart enough to split up multiple rows into multiple statements when using the SQLite backend? We could abstract out the pieces. What I have written could be adapted. It's simply a question of risk. I'm not so tied to libgda that I couldn't switch, even now. True, which is why I'm asking these questions. I think depending on GDA right now is a HUGE risk because it seems like such a moving target. I think using DBI is lower risk in terms of stability but perhaps higher risk in getting lots of DB support (because it doesn't abstract the tables and query language). 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: GDA: Status
Albert Lash [EMAIL PROTECTED] writes: One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? While not optimal, is it a practical issue? Most SQLite drivers automatically create database if the target doesn't exist (not sure about libdbi), and the tables could be created by a create new file user event. Sorry, not a question of creating the database.. It's a question of creating/updating all the GnuCash tables. For example, the auto increment column type is different on MySQL v. PG, so we'd need to know the underlying DB type to know how to create the table. As for MySQL / Postgres, I can't imagine a user sophisticated enough to want this who would be unwilling to follow some simple directions to install the model. As I said in my previous message, MythTV already shows how to do this with MySQL and PG without requiring any user intervention. I really like their model. It also allows easy DB model upgrades. However, don't take this the wrong way, I'm not advocating we ditch gda - I'm leaving that decision up to 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: GDA: Status
Phil Longstaff [EMAIL PROTECTED] writes: My memory is that I chose GDA over DBI because DBI did not seem to be maintained. In fact, there is nothing on their page re release between Nov 2005 and Feb 2007 (I remember starting the project in 2006). What we are now finding is that GDA-3 will not be maintained (I don't have any current issues with it, but if I find one, who knows how it might get fixed in the field). So, with GDA, I think we have GDA-3 which has no maintenance (and may not be on all distros) and GDA-4 which won't be released for another 9 months. Yeah, their web site certainly isn't maintained, but the project is very mature so doesn't require much work. But they certainly have made new point releases in the interim. Moving to DBI would require: 1) a procedure to create a new db. As Albert Lash mentioned, perhaps support for building sqlite tables could be built-in and external procedures could be used to build mysql/postgres tables. I'm not sure how table upgrades because of new columns would be handled. Perhaps by the time we need upgrades, GDA will be out in the wild and we could look at whether to move back. My appologies for sounding like a broken record, but if you look at MythTV they show how to support both MySQL and PG in an automated fashion. At least I'm pretty sure they can create and update tables for both DBs. We should have a plan in place at day 1 for how we'd deal with this. I DO like the MythTV model where we have a DB Schema Version number in a known table/location and then we can use that to detect whether we need updates. Then the only question I see would be forming the correct SQL statement for the correct DB to do the update. Even then I would suspect it would FAIRLY similar on all DBs, no? For example, SQLite only supports ADD COLUMN and RENAME TABLE support in ALTER TABLE. 2) potentially, an abstraction internal for each db driver just to handle any differences for each db. I suspect we might need this, yes. I just don't know how expensive this will be. 3) a new url format. For sqlite, not a problem, but would be needed for mysql/postgres. Why would we need a new URL format? Anyways, I wouldn't consider this a major issue. 4) switch gda calls to dbi calls 5) lots more. think you should be more explicit here in step two (okay, step 5). What's lots more here? I think what I want to do is create a dbi backend in the gda-dev2 tree, copy the gda code over, and just see what would be required to modify everything. That would give me a feel for the amount of effort required to switch. Do you want to do this in the gda-dev or would you like a new branch to work from? Branches are cheap. The code is almost at a stage that for many parts of it, I could abstract db access libraries. No, I probably don't want to go down that path. Hahah... Umm, maybe, maybe not. Sometimes abstraction is good. 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: GDA: Status
Nathan Buchanan [EMAIL PROTECTED] writes: The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? We'd be in the same predicament as we would be in with GDA v3 - needing to distribute our own code to make things work. I'm not saying this is ideal, just that it isn't any worse. I think it is worse... (more on this later) It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. This assumes we don't distribute any of it with our code. I believe we have done this sort of thing in the past, but it was before my time here. Most recently it was done with GOffice. However, GOffice didn't add any new dependencies that we didn't already have (except for GSF, which we ALSO included). In other words, we didn't need to significantly check for additional packages, nor did we need to require any additional packages to build GnuCash. This would NOT be the case with GDA. If we included GDA then we'd need to add a build dependency on SQLite, MySQL, and PG in order to get GDA built properly. If we could depend on GDA then we wouldn't need those additional build dependencies. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? A very valid point. -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: GDA: Status
Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: My appologies for sounding like a broken record, but if you look at MythTV they show how to support both MySQL and PG in an automated fashion. At least I'm pretty sure they can create and update tables for both DBs. I'll take a look at MythTV. The only places I had looked at were from links on the libdbi website. We should have a plan in place at day 1 for how we'd deal with this. I DO like the MythTV model where we have a DB Schema Version number in a known table/location and then we can use that to detect whether we need updates. I recently added a version number per table. At a minimum, we would need 1 for core and 1 for business. 4) switch gda calls to dbi calls 5) lots more. think you should be more explicit here in step two (okay, step 5). What's lots more here? I think what I want to do is create a dbi backend in the gda-dev2 tree, copy the gda code over, and just see what would be required to modify everything. That would give me a feel for the amount of effort required to switch. Do you want to do this in the gda-dev or would you like a new branch to work from? Branches are cheap. At this point, I'll work in gda-dev. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Hi, Sorry for the delay, but I've been busy offline most of the weekend and yesterday so I've let this thread sit for a bit. More comments inline. Nathan Buchanan [EMAIL PROTECTED] writes: So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working now, much of this energy will be lost when moving to V4. 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be there for a long time and wont get us stuck in a situation where we're spending all our time keeping up with them changing APIs out from under us. As an example, just look at what's happening in AqBanking. It's not a zero-effort task to move from AqB-2 to AqB-3. Luckily that work is limited only to a small section of Gnucash. Now imagine if we finish with GDA-4 and they move to GDA-5 (just like we almost finished with GDA-3 and now they're moving to GDA-4). Just let that simmer a bit. -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
Re: GDA: Status
Phil Longstaff [EMAIL PROTECTED] writes: Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? -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: GDA: Status
Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? I took a look at a few projects using libdbi. They seem to have some external mechanism (script) to create the db, and they also seem to have more of a permanent database idea (e.g. a reference database, a library contents database). Well, as long as queries and data modification stick to standard sql, gc could be ok. Note that there are some things which, whether standard sql or not, I would like to use if available e.g. the ability to insert multiple rows at a time (for slots) which is not supported by sqlite. We could abstract out the pieces. What I have written could be adapted. It's simply a question of risk. I'm not so tied to libgda that I couldn't switch, even now. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? While not optimal, is it a practical issue? Most SQLite drivers automatically create database if the target doesn't exist (not sure about libdbi), and the tables could be created by a create new file user event. As for MySQL / Postgres, I can't imagine a user sophisticated enough to want this who would be unwilling to follow some simple directions to install the model. However, don't take this the wrong way, I'm not advocating we ditch gda - I'm leaving that decision up to Phil. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Derek Atkins wrote: 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? According to the libgda development mailing list, they are targetting 2.26 which seems to be scheduled for Q1 2009. Depending on distro release schedules, this means it may not be out in the wild until Q3 2009. I expect the gda-dev branch to be finished long before then. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. From what I know now, we wouldn't need to redo *ALL* the work. However, it might be roughly equivalent to the amount of work to move from GDA-3 to GDA-4, which was a few weekends. A lot of the changes are simply based on the requirements of any SQL backend. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be there for a long time and wont get us stuck in a situation where we're spending all our time keeping up with them changing APIs out from under us. My memory is that I chose GDA over DBI because DBI did not seem to be maintained. In fact, there is nothing on their page re release between Nov 2005 and Feb 2007 (I remember starting the project in 2006). What we are now finding is that GDA-3 will not be maintained (I don't have any current issues with it, but if I find one, who knows how it might get fixed in the field). So, with GDA, I think we have GDA-3 which has no maintenance (and may not be on all distros) and GDA-4 which won't be released for another 9 months. Moving to DBI would require: 1) a procedure to create a new db. As Albert Lash mentioned, perhaps support for building sqlite tables could be built-in and external procedures could be used to build mysql/postgres tables. I'm not sure how table upgrades because
Re: GDA: Status
Hi, On Tue, Jun 3, 2008 at 8:19 AM, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Sorry for the delay, but I've been busy offline most of the weekend and yesterday so I've let this thread sit for a bit. More comments inline. Nathan Buchanan [EMAIL PROTECTED] writes: So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working now, much of this energy will be lost when moving to V4. 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? We'd be in the same predicament as we would be in with GDA v3 - needing to distribute our own code to make things work. I'm not saying this is ideal, just that it isn't any worse. It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. This assumes we don't distribute any of it with our code. I believe we have done this sort of thing in the past, but it was before my time here. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? A very valid point. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. This would be a significant shift in direction and it really would be up to Phill to make this change (as he's doing the work!). Honestly I'd have no objection to this, but the decision needs to come (IMHO) from the person doing the work. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. Point taken, absolutes are hard to defend ;) Nathan My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be
Re: GDA: Status
Derek Atkins wrote: gncInvoice.c in particular the code that implements the invoice and payment processing and the balancing code to make sure payment are split across invoices properly. I have found that the current implementation of this particular functionality doesn't work that well, as it assumes payments will always follow invoices/bills. In the invoice world this is usually the case, but in the case of bills, the payment will often be entered first (the bank statement gets reconciled to ensure the customer paid before shipping the goods, and both the payment from the customer and the payment to the supplier is captured in the process), the supplier takes their time getting their bill to you so the bill is captured long after the payment was made. On top of this, you may have captured the bills in a different order to the captured payments, so the payment splits end up not making much sense. Then, if you unpost a bill to correct a mistake, it further complicates things, because now the bill total may be different and the payment splits make even less sense. This seems to affect the payable and receivable aging, I have often seen cases of where payable aging says the vendor is owed X, but the final total on the account is zero. As a result I have learned to ignore payable aging entirely. Calculating which invoices are paid and which aren't is a non trivial process, for my purposes I implemented a way to flag an invoice as unpaid if all the payments made to date by the supplier don't exceed the sum of all invoices up until that invoice. Getting that right gave me a headache. I suspect that after an invoice or a payment is posted (or reposted) for an invoice or bill, what should probably happen is that the flags indicating paid / unpaid get reset from scratch each time. This way inaccuracies can get smoothed out over time. In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. This has nothing to do with the data in the XML file. I honestly forget why the txn-type was created, and I dont remember where it's used. The data is respected though - if you manually change the sign, load it into gnucash and save it again, the invoice stays an invoice, and the payment stays a payment. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
hi, Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: gncInvoice.c in particular the code that implements the invoice and payment processing and the balancing code to make sure payment are split across invoices properly. I have found that the current implementation of this particular functionality doesn't work that well, as it assumes payments will always follow invoices/bills. Huh! It shouldn't be making that assumption. Indeed, one of my test cases was applying a Payment before I post the invoice, and that certainly works in my testing. This is partly where the sign issue comes in. The code searches for open lots and uses the positive/negative balance to determine how to find the customer. Yes, this algorithm could be improved. In the invoice world this is usually the case, but in the case of bills, the payment will often be entered first (the bank statement gets reconciled to ensure the customer paid before shipping the goods, and both the payment from the customer and the payment to the supplier is captured in the process), the supplier takes their time getting their bill to you so the bill is captured long after the payment was made. Eh? I receive a bill from my vendor. It's not due for another 20 days. I enter it into gnucash and then later on pay it. In your case you're talking about a completely different paradigm. You're talking POS/Orders, and the gnucash business features don't implement that right now. For that you should probably just forego the business features because you're never in a situation where a customer owes you money. On top of this, you may have captured the bills in a different order to the captured payments, so the payment splits end up not making much sense. Then, if you unpost a bill to correct a mistake, it further complicates things, because now the bill total may be different and the payment splits make even less sense. You can choose the first item to get paid. yes, if you unpost then it can get confused. There's certainly some post/unpost/pay series that gets it very confused but I haven't been able to reproduce this case in my testing. This seems to affect the payable and receivable aging, I have often seen cases of where payable aging says the vendor is owed X, but the final total on the account is zero. As a result I have learned to ignore payable aging entirely. Calculating which invoices are paid and which aren't is a non trivial process, for my purposes I implemented a way to flag an invoice as unpaid if all the payments made to date by the supplier don't exceed the sum of all invoices up until that invoice. Getting that right gave me a headache. I suspect that after an invoice or a payment is posted (or reposted) for an invoice or bill, what should probably happen is that the flags indicating paid / unpaid get reset from scratch each time. This way inaccuracies can get smoothed out over time. The flags are purely based on the transaction lots. What's going on is that the algorithm to move overpayments between lots is getting confused. Those extra A/R (and A/P) transactions don't get removed when you unpost and invoice, so that's probably related to the issue. In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. This has nothing to do with the data in the XML file. I honestly forget why the txn-type was created, and I dont remember where it's used. The data is respected though - if you manually change the sign, load it into gnucash and save it again, the invoice stays an invoice, and the payment stays a payment. It's respected in some places. It's meaningless in others. Regards, Graham -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: credit notes-invoices-payments (was: Re: GDA: Status)
[[ Shoot! I keep forgetting to reply to list... Sorry Derek for all the doubles I cause in your mailbox ]] Note: I have changed the subject to separate this topic from the GDA one. On Sunday 1 June 2008, you wrote: On top of this, you may have captured the bills in a different order to the captured payments, so the payment splits end up not making much sense. Then, if you unpost a bill to correct a mistake, it further complicates things, because now the bill total may be different and the payment splits make even less sense. You can choose the first item to get paid. yes, if you unpost then it can get confused. There's certainly some post/unpost/pay series that gets it very confused but I haven't been able to reproduce this case in my testing. I have. See bug 488035: http://bugzilla.gnome.org/show_bug.cgi?id=488035 That's one scenario that does confuse the internal logic. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Derek Atkins wrote: Eh? I receive a bill from my vendor. It's not due for another 20 days. I enter it into gnucash and then later on pay it. Some vendors are COD only, which means the payment will almost always come before the invoice. Or the payment is captured before the bill is captured, either way has the same effect. Your algorithm cannot make any assumptions as to the order that information will be captured into gnucash. In your case you're talking about a completely different paradigm. You're talking POS/Orders, and the gnucash business features don't implement that right now. For that you should probably just forego the business features because you're never in a situation where a customer owes you money. Both our customers and our accountant require invoices regardless of when and how payment is made, again, this is a legal requirement. As a result, using the business features is mandatory for us. You can choose the first item to get paid. yes, if you unpost then it can get confused. There's certainly some post/unpost/pay series that gets it very confused but I haven't been able to reproduce this case in my testing. I have, in three separate sets of accounts, reproducing it is not difficult. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Quoting Graham Leggett [EMAIL PROTECTED]: In your case you're talking about a completely different paradigm. You're talking POS/Orders, and the gnucash business features don't implement that right now. For that you should probably just forego the business features because you're never in a situation where a customer owes you money. Both our customers and our accountant require invoices regardless of when and how payment is made, again, this is a legal requirement. As a result, using the business features is mandatory for us. You're conflating two issues! You're conflating the I need to send a piece of paper to my customer that details what they bought and I need to keep track (in GnuCash) of what customers owe/paid me. These are two completely different issues, and there's no reason that they cannot be separated. Indeed, in your case I would HIGHLY recommend that you separate them, because I suspect the legal requirement is the former, not the latter. Note: There are OTHER (non-GnuCash) solutions to problem #1. I highly recommend invoice.sty. You can choose the first item to get paid. yes, if you unpost then it can get confused. There's certainly some post/unpost/pay series that gets it very confused but I haven't been able to reproduce this case in my testing. I have, in three separate sets of accounts, reproducing it is not difficult. It's certainly not a use case that I've ever run into. If you can so readily reproduce it from a known state then could you please file a bug report on this? Or comment on the existing bug report that Geert mentioned in a previous email? Regards, -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: GDA: Status
Derek Atkins wrote: Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). Can you confirm in more detail exactly which part of the code makes this assumption? In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. Changing the sign manually on an invoice and saving the file shows correct figures for that particular customer, both from within gnucash, and from within my web statements (which ignore the sign of the transactions completely). Is the sign check shortcut being used in other reports? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). Can you confirm in more detail exactly which part of the code makes this assumption? gncInvoice.c in particular the code that implements the invoice and payment processing and the balancing code to make sure payment are split across invoices properly. I also believe (but I'm not 100% sure) that the code that looks for an invoice from a transaction also makes that assumption. In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from trans-txn-type), and b) which invoice this transaction is associated with. This has nothing to do with the data in the XML file. I honestly forget why the txn-type was created, and I dont remember where it's used. Changing the sign manually on an invoice and saving the file shows correct figures for that particular customer, both from within gnucash, and from within my web statements (which ignore the sign of the transactions completely). Yes, but it'll screw up the lot balancing that's used for when an invoice is paid and determining which lot to use for posting. Is the sign check shortcut being used in other reports? AFAIK it's not used in the reports at all, at least not directly. Regards, Graham -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: GDA: Status
Derek Atkins wrote: Daniel, My major concern here is that a year ago you were rallying for GDA and GdaQuery. Phil threw out a bunch of his work to target GDA-3 with GdaQuery. Now here we are, 6 or 9 months later, and the GDA team has moved on to GDA-4 already and are dropping GdaQuery, the very interface you were so adamant was the greatest thing since sliced bread. Phil has found a number of apparently major bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4 isn't nearly as usable as GDA-3. So, what's Phil supposed to do? Work with GDA-3 with the known bugs, knowing that those bugs will never be fixed? Work with GDA-4 which is just broken and cant be tested and hope that the GDA team gets it working and makes a release early enough that GnuCash can actually use it? If we stay with GDA-3, Daniel could provide fixes (or could commit fixes), but there's no guarantee that there would be any more releases. My suggestion to include GDA-3 in the GC tree was simply so that we *could* guarantee and rely on GDA releases, namely, our own, and our dependencies would then be on sqlite, mysql and pgsql libraries. If or when GDA-4 is solid enough and released or soon-to-be released, we could switch to it. It seems to me to be similar to some of the libraries which lived under lib for awhile (e.g. goffice-0.0.4). Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Why did the GDA team decide to drop GdaQuery? And why did the move to GDA-4 break all the backends? That seems like a very bad idea to me. From an e-mail on the gnome-db developer mailing list: On Wed, 2008-03-19 at 22:37 +0100, Vivien Malerba wrote: After a long time, I'm pleased to announce the first version of Libgda which will lead to a V4. This version is a major rework of the library's internals to correct the conception errors that were made with previous versions; it also aims at having a smaller yet more powerfull and easier to understand API, and to close some long standing bugs. A non detailled list of changes is: - Easier to understand and to use API, with less strange path usage - Reduce the size of the library (almost half the size and half the symbols) - Easier connection opening (removal of the GdaClient object) - Merge of the GdaQuery and GdaCommand into only one object to represent statements - New adaptative SQL parser (can be adaptated to each DBMS's SQL syntax) - New database based dictionary which can handle namespaces - Rework of the database adaptators (providers) for easier maintenance and more features - Sample skeleton database adaptators to make it easy to write a database adaptator for a new database type - Updated documentation A few warnings however: - This is still an early version which probably has a lot of bugs and as such it should not be used in a production environment. - Most of the database adaptators (providers) need to be re-written, particularly MySQL (which is currently being done) and Oracle - Libgnomedb has not yet been updated and won't compile with this version One problem (which I just asked about on the gda list) is why GDA-3 isn't being maintained while GDA-4 is being worked on. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
2008/5/30 Derek Atkins [EMAIL PROTECTED]: Daniel, My major concern here is that a year ago you were rallying for GDA and GdaQuery. Phil threw out a bunch of his work to target GDA-3 with GdaQuery. Now here we are, 6 or 9 months later, and the GDA team has moved on to GDA-4 already and are dropping GdaQuery, the very interface you were so adamant was the greatest thing since sliced bread. Phil has found a number of apparently major bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4 isn't nearly as usable as GDA-3. For now the GDA team is realy limited in developers. Vivien, the main developer, concentrates its work on V4 witch is a major re-work of V3, most of the work on V3 it's stopped becouse at the moment other developers have no time enough to fix this bugs, I hope to they or even me find the time to work around V3. So, what's Phil supposed to do? Work with GDA-3 with the known bugs, knowing that those bugs will never be fixed? Work with GDA-4 which is just broken and cant be tested and hope that the GDA team gets it working and makes a release early enough that GnuCash can actually use it? Fixing bugs on V3 is mainly done by some users/developers still using it, I think any one have time enough to help to fix this bugs. GDA V4 helps to simplify most operations and create, execute and manipulate SQL queries in a simply way. Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? The developer must evalulate the alternatives and use it if he want it. But ofcourse this desition will be affected over the time frame you want to archive objectives. I know that this is not new, but just need to evaluate the alternatives, I realy don't know any thing about dbi, but why I think GDA V4 is a good choice: * It is based on GLib * It will be propoused to be included on GNOME * It's licended under LGPL * As others, is a layer to have access to a different DBS using the same code * As a GLib based library could be, more or less, easy to have bindings to different languages * V4, don't know V3, have XSLT transformations to access to data * You can use virtual connections, have access to a tables in a different DB as it was a local table; allows you, for example, copy data from a table in a MySQL to a PostgreSQL database. * And more.. * V3 has a more complicated set of objects, most of them removed for simplicity in V4 Why did the GDA team decide to drop GdaQuery? And why did the move to GDA-4 break all the backends? That seems like a very bad idea to me. In V3 if you try to create by hand a Query, you must use a lot of GObjects and properties to have a GdaQuery object, witch is realy complicated way to describe or understand its parts. On version 4, you have just a GObject called GdaStatement and a tree of C structures describing the SQL query parts, in a realy simple way. To see a better explanation about this look at GDA documentation (boulding from svn). But there are a lot of API/ABI changes to get a more easy to use library. Daniel Espinosa [EMAIL PROTECTED] writes: I've read all your other comments and is the same as before I try to re-write most of the GC's core, you don't want to lesen the others, the I don't plan to work on GC's as actualy is. If I can help Phil improving GDA it's Ok. If some others work to modify the GC's core to create a bussiness library and a GUI aplication I'll help. If the bussiness library is written to sue a DB, using GDA or not, I'll help. And please Derek, don't reply this if you want to insult or vociferous. 2008/5/26 Derek Atkins [EMAIL PROTECTED]: Can't you just use CREATE IF NOT EXIST ? Or is that not portable enough across various SQL implementations? Part of me is really thinking that GDA is more trouble than it's worth. I'm sure Esodan will vociferously argue against this, but perhaps we should drop GDA and choose something that actually works? -derek Quoting Phil Longstaff [EMAIL PROTECTED]: Graham Leggett wrote: Phil Longstaff wrote: Well, V4 basically works with the sqlite provider. There were a number of memory leaks and other small issues. However, there are a number of problems with the V4 mysql provider - it's not ready for use. I've decided to switch back to V3 for now. I'll continue to supply patches and if I have to, I'll pull it into the tree under 'lib'. Considering that V3 is not being actively developed, and that bugfixes to v3 won't be accepted, is it not safer to develop for V4, and get the upstream project to fix any problems involved? How far away is the V4 mysql provider? I don't know how far away the V4 provider is. They have a meta-information system which allows you to access info about the db structure (e.g. which tables exist) and the meta-information system has been redesigned for V4. It hasn't been implemented for mysql yet,
Re: GDA: Status
2008/5/30 Derek Atkins [EMAIL PROTECTED]: Daniel Espinosa [EMAIL PROTECTED] writes: I just want to point that if you use V4 you may will get inmediatly access to SQLite database, and after the API is stable enough the other database providers will be on the road. How long in the future is this down the road? I'm concerned about your statement: after the API is stable enough. That certainly does not send me warm fuzzies. :( Of course it will depend on the time frame you have. May be for Phil, its better to find a way archive the same functionality or he wants or try to fix himself, or wait to other to fix it. I see that the work made on GDA backend is realy advanced and may you want to see your work on the main tree, then may be is better to use V3 and try to fix the problem in a some way. Sorry I haven't time to see the Phil's work to see if I can help or even find a way to archive, as a temporaly solution, the same functionality. I'm trying to get a library using V4, becouse my work will be too later after V4 will be realesed, then I'm using and reporting/fixing bugs on it. I found V4 more easy to archive my objectives. Of course Phil's backend work have other priorities. I don't think is a good idea to have a copy of GDA in GnuCash. I agree completely. I really don't think we want a copy of GDA in GnuCash. -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 -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
2008/5/31 Daniel Espinosa [EMAIL PROTECTED]: 2008/5/30 Derek Atkins [EMAIL PROTECTED]: Daniel Espinosa [EMAIL PROTECTED] writes: I just want to point that if you use V4 you may will get inmediatly access to SQLite database, and after the API is stable enough the other database providers will be on the road. How long in the future is this down the road? I'm concerned about your statement: after the API is stable enough. That certainly does not send me warm fuzzies. :( Sorry to answer: as any Free Software Project, there's no time to fix it. If most of developers want to switch the default file format to use SQLite first than the others, then GDA V4 is the better choice. The API is near to be stable, I can't say when. I didn't see too much changes to the API in the last weeks, I've propoused some of them and they are work in progress. For bug fixing, there are a lot to test before to get an stable version, may be a little months if the GDA team can get help enough to do the work. Of course it will depend on the time frame you have. May be for Phil, its better to find a way archive the same functionality or he wants or try to fix himself, or wait to other to fix it. I see that the work made on GDA backend is realy advanced and may you want to see your work on the main tree, then may be is better to use V3 and try to fix the problem in a some way. Sorry I haven't time to see the Phil's work to see if I can help or even find a way to archive, as a temporaly solution, the same functionality. I'm trying to get a library using V4, becouse my work will be too later after V4 will be realesed, then I'm using and reporting/fixing bugs on it. I found V4 more easy to archive my objectives. Of course Phil's backend work have other priorities. I don't think is a good idea to have a copy of GDA in GnuCash. I agree completely. I really don't think we want a copy of GDA in GnuCash. -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 -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working now, much of this energy will be lost when moving to V4. 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. Phil, do you have a preference? It's probably your preference that counts ;) Nathan On Fri, May 30, 2008 at 3:41 PM, Charles Day [EMAIL PROTECTED] wrote: Getting back to the gda stuff, the key question seems to be: Can support for mysql and postgresql wait? If so, then V4 seems like a good choice to me, since Phil has said (I think) that it works well enough with sqlite for our purposes. Support for the other databases can be added as V4 evolves. I got the impression from the various updates over past weeks that V3 wasn't satisfactory for even ONE of sqlite, mysql, or postgresql -- unless we fork it off and customize it. My $0.02, but since I'm not contributing to this part of GnuCash, feel free to ignore it. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Even if you are on the right track, you'll get run over if you just sit there - Will Rogers ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Nathan Buchanan wrote: 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. I agree with this. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I would like postgres, but I would prefer a stable and supported library more in the long run even if it mean waiting longer. Use of a library attracts development of that library, I think if gnucash uses V4 it will be an extra reason for V4 to be maintained and supported. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Geert Janssens [EMAIL PROTECTED] writes: On Wednesday 28 May 2008, Derek Atkins wrote: Geert Janssens [EMAIL PROTECTED] writes: On Tuesday 27 May 2008, you wrote: Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. Heh, I have been bitten by that one too ! I have chosen to keep credit notes (negative invoices) outside of the business tools for that reason. This works, but my credit notes have to do without the added consistency checks done by the business tools. Currently you can sort of do a credit note through the Process Payment mechanism, but it's not perfect. How does this work ? A link to some documentation is also ok... A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. Honestly, I wrote the business features for my own use, and indeed it's worked quite fine for me. The fact that other people can use them at all is just gravy. You're welcome to take the same approach and write the code you need to get your work done. This *IS* the devel list after all! Patches are always welcome. I am aware of that as you could read in my earlier mail in this topic. Alas for several reasons, I am currently unable to provide patches. And I said as well my comments were not meant to complain. Do you prefer I create a bug report for this issue ? I will gladly do so. Sorry, that response wasn't necessarily directed at you. On the other hand this *IS* the -devel list so there's a tacit assumption that questions are development-related and not how do I do X. Geert -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: GDA: Status
Daniel, My major concern here is that a year ago you were rallying for GDA and GdaQuery. Phil threw out a bunch of his work to target GDA-3 with GdaQuery. Now here we are, 6 or 9 months later, and the GDA team has moved on to GDA-4 already and are dropping GdaQuery, the very interface you were so adamant was the greatest thing since sliced bread. Phil has found a number of apparently major bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4 isn't nearly as usable as GDA-3. So, what's Phil supposed to do? Work with GDA-3 with the known bugs, knowing that those bugs will never be fixed? Work with GDA-4 which is just broken and cant be tested and hope that the GDA team gets it working and makes a release early enough that GnuCash can actually use it? Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? Why did the GDA team decide to drop GdaQuery? And why did the move to GDA-4 break all the backends? That seems like a very bad idea to me. -derek Daniel Espinosa [EMAIL PROTECTED] writes: I've read all your other comments and is the same as before I try to re-write most of the GC's core, you don't want to lesen the others, the I don't plan to work on GC's as actualy is. If I can help Phil improving GDA it's Ok. If some others work to modify the GC's core to create a bussiness library and a GUI aplication I'll help. If the bussiness library is written to sue a DB, using GDA or not, I'll help. And please Derek, don't reply this if you want to insult or vociferous. 2008/5/26 Derek Atkins [EMAIL PROTECTED]: Can't you just use CREATE IF NOT EXIST ? Or is that not portable enough across various SQL implementations? Part of me is really thinking that GDA is more trouble than it's worth. I'm sure Esodan will vociferously argue against this, but perhaps we should drop GDA and choose something that actually works? -derek Quoting Phil Longstaff [EMAIL PROTECTED]: Graham Leggett wrote: Phil Longstaff wrote: Well, V4 basically works with the sqlite provider. There were a number of memory leaks and other small issues. However, there are a number of problems with the V4 mysql provider - it's not ready for use. I've decided to switch back to V3 for now. I'll continue to supply patches and if I have to, I'll pull it into the tree under 'lib'. Considering that V3 is not being actively developed, and that bugfixes to v3 won't be accepted, is it not safer to develop for V4, and get the upstream project to fix any problems involved? How far away is the V4 mysql provider? I don't know how far away the V4 provider is. They have a meta-information system which allows you to access info about the db structure (e.g. which tables exist) and the meta-information system has been redesigned for V4. It hasn't been implemented for mysql yet, so when gc starts, it tries to create all of the tables, even if they already exist. Note that it was a meta-information bug which was causing a problem in the gc-V3 code which was not accepted. The bug is that if you delete all db tables and then ask libgda to update the meta-information, it still thinks that the 2nd table exists (usually, billterms) so that it won't be created. This could happen when you are trying to save-as to a db, so billterms won't be saved, and lots of business objects will be screwed up. I see 3 possibilities: 1) Do libgda V3 maintenance ourselves by sending in patches and asking for them to be applied. For the particular bug I found, I didn't send in a patch, but asked for the bug to be fixed. Maybe they won't fix bugs but will apply patches. They would probably not create new tarballs, so anyone who wanted to use gc-libgda would need to check out the V3 trunk from svn and build from source. 2) Pull the libgda-V3 branch into the gc tree under lib. The GC team would maintain it. This has the advantage that it would not be an external dependency any longer, so anyone who wanted to try the gda backend could. The obvious disadvantage is a mess of code that nobody knows but that we need to maintain. Once libgda-V4 is further along, I can switch back to V4. 3) Change my decision and switch back to V4. I have basic operation with sqlite working. There is at least 1 regression (I can't create the index on the slots table) which would have performance implications. I don't know where the problem with index creation is. However, there are some improvements. The libgda-V4 statement structures can represent SQL operations which were not possible in V3, and which would improve performance. However, as I said above, the mysql provider is missing some major functionality. I don't know about postgresql. There are other issues with the whole gda backend which I need to work on and which are independent of which version of libgda is used: 1) some of
Re: GDA: Status
Daniel Espinosa [EMAIL PROTECTED] writes: I just want to point that if you use V4 you may will get inmediatly access to SQLite database, and after the API is stable enough the other database providers will be on the road. How long in the future is this down the road? I'm concerned about your statement: after the API is stable enough. That certainly does not send me warm fuzzies. :( I don't think is a good idea to have a copy of GDA in GnuCash. I agree completely. I really don't think we want a copy of GDA in GnuCash. -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: GDA: Status
Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). That check is in place in order to maintain this invariant. Removing the check would cause the underlying logic to get confused and potentially not balance out properly. I suppose one COULD go through an re-work all the logic first to remove the value sign implies transaction type. Then you could remove the negative value check. Keep in mind that the printed note does not have to be a GnuCash Invoice. You just need a some printed note that you can send. At least that's what I'm reading from you, right? So that would imply that you COULD write a *new* Credit Note report that happens to work off of a different type of transaction than an invoice. Regards, Graham -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: GDA: Status
[[Sorry, forgot to reply to list]] I have created a feature request for credit notes in bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=535781 I have added most of the parts of this thread I considered relevant, together with some freewheeling on the implementation. Although I'll probably not be the one to implement it, in this way the information won't get lost. Geert On Friday 30 May 2008, Derek Atkins wrote: Quoting Graham Leggett [EMAIL PROTECTED]: Derek Atkins wrote: A Process Payment gives you that Negative number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers. This doesn't solve the problem of the need to give your customer a credit note. This requirement exists in law, as the credit note contains tax refund details of VAT amounts on the invoice. The real fix it to take out the error check that prevents invoices being posted that have negative totals. Unfortunately it's not that easy. That check is in there because the underlying code uses the Value + AccountType to determine if this is an Invoice or a Payment. All the linkage logic is based on the invariant that an Invoice is positive and a Payment is negative (obviously the numeric positive/negative is different for A/R and A/P, but let's not confuse the issue). That check is in place in order to maintain this invariant. Removing the check would cause the underlying logic to get confused and potentially not balance out properly. I suppose one COULD go through an re-work all the logic first to remove the value sign implies transaction type. Then you could remove the negative value check. Keep in mind that the printed note does not have to be a GnuCash Invoice. You just need a some printed note that you can send. At least that's what I'm reading from you, right? So that would imply that you COULD write a *new* Credit Note report that happens to work off of a different type of transaction than an invoice. Regards, Graham -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Getting back to the gda stuff, the key question seems to be: Can support for mysql and postgresql wait? If so, then V4 seems like a good choice to me, since Phil has said (I think) that it works well enough with sqlite for our purposes. Support for the other databases can be added as V4 evolves. I got the impression from the various updates over past weeks that V3 wasn't satisfactory for even ONE of sqlite, mysql, or postgresql -- unless we fork it off and customize it. My $0.02, but since I'm not contributing to this part of GnuCash, feel free to ignore it. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Graham Leggett [EMAIL PROTECTED] writes: Derek Atkins wrote: Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? Come across to Apache sometime. We take our users seriously over there. Last I checked Apache had a whole big funded foundation backing their development. Apples and kumquats, I'm afraid. Regards, Graham -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: GDA: Status
Derek Atkins wrote: Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? Come across to Apache sometime. We take our users seriously over there. Last I checked Apache had a whole big funded foundation backing their development. Apples and kumquats, I'm afraid. Having been a member of the foundation for some time (you are using some of my code contributions to host your website), I can confirm to you that Apache doesn't take it's users seriously because of big funding (which Apache doesn't have), but because without users there would be zero point in writing the software at all. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Derek Atkins [EMAIL PROTECTED] writes: Previous, Graham said: Users needs win I am afraid, if necessary I'll patch gnucash to do it myself. Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? While it's true that it's always nice to have a good user experience, the code was written by developers generally for their own use. The business features certainly qualify here. My personal philosophy here is you get what you pay for. Derek, I'm not sure what you hope to accomplish by laughing at people who want to make the app better, and advocate for users, but it's really off-putting. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp9FS2ZDiOST.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Hi, On Donnerstag, 29. Mai 2008, Josh Sled wrote: [...] Derek, I'm not sure what you hope to accomplish by laughing at people who want to make the app better, and advocate for users, but it's really off-putting. [...] Hmm, that comes from the guy who slammed me when I was merely asking about privacy issues in IRC, if I remember correctly :-) Actually, that's why I never bothered again showing up in gnucash's IRC since, so obviously that didn't help too much either... Regards Martin -- Things are only impossible until they're not Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
On Wednesday 28 May 2008, Derek Atkins wrote: Geert Janssens [EMAIL PROTECTED] writes: On Tuesday 27 May 2008, you wrote: Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. Heh, I have been bitten by that one too ! I have chosen to keep credit notes (negative invoices) outside of the business tools for that reason. This works, but my credit notes have to do without the added consistency checks done by the business tools. Currently you can sort of do a credit note through the Process Payment mechanism, but it's not perfect. How does this work ? A link to some documentation is also ok... Honestly, I wrote the business features for my own use, and indeed it's worked quite fine for me. The fact that other people can use them at all is just gravy. You're welcome to take the same approach and write the code you need to get your work done. This *IS* the devel list after all! Patches are always welcome. I am aware of that as you could read in my earlier mail in this topic. Alas for several reasons, I am currently unable to provide patches. And I said as well my comments were not meant to complain. Do you prefer I create a bug report for this issue ? I will gladly do so. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
2008/5/26 Phil Longstaff [EMAIL PROTECTED]: Graham Leggett wrote: Phil Longstaff wrote: Well, V4 basically works with the sqlite provider. There were a number of memory leaks and other small issues. However, there are a number of problems with the V4 mysql provider - it's not ready for use. I've decided to switch back to V3 for now. I'll continue to supply patches and if I have to, I'll pull it into the tree under 'lib'. Considering that V3 is not being actively developed, and that bugfixes to v3 won't be accepted, is it not safer to develop for V4, and get the upstream project to fix any problems involved? How far away is the V4 mysql provider? I don't know how far away the V4 provider is. They have a meta-information system which allows you to access info about the db structure (e.g. which tables exist) and the meta-information system has been redesigned for V4. It hasn't been implemented for mysql yet, so when gc starts, it tries to create all of the tables, even if they already exist. Note that it was a meta-information bug which was causing a problem in the gc-V3 code which was not accepted. The bug is that if you delete all db tables and then ask libgda to update the meta-information, it still thinks that the 2nd table exists (usually, billterms) so that it won't be created. This could happen when you are trying to save-as to a db, so billterms won't be saved, and lots of business objects will be screwed up. I see 3 possibilities: 1) Do libgda V3 maintenance ourselves by sending in patches and asking for them to be applied. For the particular bug I found, I didn't send in a patch, but asked for the bug to be fixed. Maybe they won't fix bugs but will apply patches. They would probably not create new tarballs, so anyone who wanted to use gc-libgda would need to check out the V3 trunk from svn and build from source. 2) Pull the libgda-V3 branch into the gc tree under lib. The GC team would maintain it. This has the advantage that it would not be an external dependency any longer, so anyone who wanted to try the gda backend could. The obvious disadvantage is a mess of code that nobody knows but that we need to maintain. Once libgda-V4 is further along, I can switch back to V4. 3) Change my decision and switch back to V4. I have basic operation with sqlite working. There is at least 1 regression (I can't create the index on the slots table) which would have performance implications. I don't know where the problem with index creation is. However, there are some improvements. The libgda-V4 statement structures can represent SQL operations which were not possible in V3, and which would improve performance. However, as I said above, the mysql provider is missing some major functionality. I don't know about postgresql. I just want to point that if you use V4 you may will get inmediatly access to SQLite database, and after the API is stable enough the other database providers will be on the road. I don't think is a good idea to have a copy of GDA in GnuCash. There are other issues with the whole gda backend which I need to work on and which are independent of which version of libgda is used: 1) some of the dialogs (e.g. price editor) create an object when the dialog is opened and then modify it as the dialog is used. This can cause commit requests for objects which break db constraints (a price must have a commodity, but a save request may come before the commodity is set). Fixing this requires a change to db logic to only create the object when 'OK' is pressed. 2) versions for tables and handling of version updates I had decided to stay with V3 because it would not be a step backwards in functionality. I wanted to try V4 to see what shape it was in, to get some experience with it, and to provide some feedback to the developers before they release. I think I'll stay with V3 for now and monitor V4. When they implement the V4 mysql meta-info code, I'll reconsider switching. I'll also do a bit of testing to see how postgresql looks. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
I've read all your other comments and is the same as before I try to re-write most of the GC's core, you don't want to lesen the others, the I don't plan to work on GC's as actualy is. If I can help Phil improving GDA it's Ok. If some others work to modify the GC's core to create a bussiness library and a GUI aplication I'll help. If the bussiness library is written to sue a DB, using GDA or not, I'll help. And please Derek, don't reply this if you want to insult or vociferous. 2008/5/26 Derek Atkins [EMAIL PROTECTED]: Can't you just use CREATE IF NOT EXIST ? Or is that not portable enough across various SQL implementations? Part of me is really thinking that GDA is more trouble than it's worth. I'm sure Esodan will vociferously argue against this, but perhaps we should drop GDA and choose something that actually works? -derek Quoting Phil Longstaff [EMAIL PROTECTED]: Graham Leggett wrote: Phil Longstaff wrote: Well, V4 basically works with the sqlite provider. There were a number of memory leaks and other small issues. However, there are a number of problems with the V4 mysql provider - it's not ready for use. I've decided to switch back to V3 for now. I'll continue to supply patches and if I have to, I'll pull it into the tree under 'lib'. Considering that V3 is not being actively developed, and that bugfixes to v3 won't be accepted, is it not safer to develop for V4, and get the upstream project to fix any problems involved? How far away is the V4 mysql provider? I don't know how far away the V4 provider is. They have a meta-information system which allows you to access info about the db structure (e.g. which tables exist) and the meta-information system has been redesigned for V4. It hasn't been implemented for mysql yet, so when gc starts, it tries to create all of the tables, even if they already exist. Note that it was a meta-information bug which was causing a problem in the gc-V3 code which was not accepted. The bug is that if you delete all db tables and then ask libgda to update the meta-information, it still thinks that the 2nd table exists (usually, billterms) so that it won't be created. This could happen when you are trying to save-as to a db, so billterms won't be saved, and lots of business objects will be screwed up. I see 3 possibilities: 1) Do libgda V3 maintenance ourselves by sending in patches and asking for them to be applied. For the particular bug I found, I didn't send in a patch, but asked for the bug to be fixed. Maybe they won't fix bugs but will apply patches. They would probably not create new tarballs, so anyone who wanted to use gc-libgda would need to check out the V3 trunk from svn and build from source. 2) Pull the libgda-V3 branch into the gc tree under lib. The GC team would maintain it. This has the advantage that it would not be an external dependency any longer, so anyone who wanted to try the gda backend could. The obvious disadvantage is a mess of code that nobody knows but that we need to maintain. Once libgda-V4 is further along, I can switch back to V4. 3) Change my decision and switch back to V4. I have basic operation with sqlite working. There is at least 1 regression (I can't create the index on the slots table) which would have performance implications. I don't know where the problem with index creation is. However, there are some improvements. The libgda-V4 statement structures can represent SQL operations which were not possible in V3, and which would improve performance. However, as I said above, the mysql provider is missing some major functionality. I don't know about postgresql. There are other issues with the whole gda backend which I need to work on and which are independent of which version of libgda is used: 1) some of the dialogs (e.g. price editor) create an object when the dialog is opened and then modify it as the dialog is used. This can cause commit requests for objects which break db constraints (a price must have a commodity, but a save request may come before the commodity is set). Fixing this requires a change to db logic to only create the object when 'OK' is pressed. 2) versions for tables and handling of version updates I had decided to stay with V3 because it would not be a step backwards in functionality. I wanted to try V4 to see what shape it was in, to get some experience with it, and to provide some feedback to the developers before they release. I think I'll stay with V3 for now and monitor V4. When they implement the V4 mysql meta-info code, I'll reconsider switching. I'll also do a bit of testing to see how postgresql looks. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing
Re: GDA: Status
Geert Janssens [EMAIL PROTECTED] writes: [[Sorry, this was meant to go on the list as well]] On Tuesday 27 May 2008, you wrote: Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. Heh, I have been bitten by that one too ! I have chosen to keep credit notes (negative invoices) outside of the business tools for that reason. This works, but my credit notes have to do without the added consistency checks done by the business tools. Currently you can sort of do a credit note through the Process Payment mechanism, but it's not perfect. Honestly, I wrote the business features for my own use, and indeed it's worked quite fine for me. The fact that other people can use them at all is just gravy. You're welcome to take the same approach and write the code you need to get your work done. This *IS* the devel list after all! Patches are always welcome. But put it this way, Derek can throw as many tantrums as he likes, we plan to use gnucash to move from a small business to a big business (for now). :) I'd be very interested to hear of your success ! Hahahah... Graham, you're so funny! Just one recommendation: don't quit your day job. :-P Seriously, though, if you can get GnuCash to work for you, great! More power to you. But when things stop working because GASP GnuCash changed their data structures, please remember that we warned you. Previous, Graham said: Users needs win I am afraid, if necessary I'll patch gnucash to do it myself. Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? While it's true that it's always nice to have a good user experience, the code was written by developers generally for their own use. The business features certainly qualify here. My personal philosophy here is you get what you pay for. Again, you're welcome to patch gnucash to do it yourself.. And I wholeheartedly encourage you to do so! Geert -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: GDA: Status
Derek Atkins wrote: Hahahahahahaha!! Wow, now you're REAY funny! Have you forgotten that GnuCash is a Volunteer effort? *laughs* Users? Come across to Apache sometime. We take our users seriously over there. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
On Tuesday 27 May 2008, Graham Leggett wrote: Derek Atkins wrote: It sounds like you really want GnuE. I suggest you look there. ZoneEdit DNS services for this domain have expired. Looks like it is a dead project to me. That's the comment I read in google, but for me the link (http://www.gnuenterprice.org) itself works fine. The last news item is from August 2007 though, so it may indeed be a dead project. I'm in a similar position as you are. I have been using Gnucash for a couple of years now and I am very pleased with it. On the other hand, I find it hard to have this program cooperate with other applications I am using (I am a heavy OpenOffice user for many things, I have an inventory database in Postgresql,...). By no means this is meant as a complaint. And I know: patches are welcome. But since I am currently unable to provide those, I'm stuck with either cumbersome integration or look for something else. And I have been looking around, although I didn't migrate yet because of the huge effort it usually takes: there's * Compiere: it does ERP (enterprise resource planning), BPM (Business Project Management) and accounting. It's maintained by a company also called Compiere, the product is open source based, although it seems the company is heading to closing the source. That's why there is now a fork: * Adempiere: this is a fully open source fork of Compiere. It aims to remain as compatible with Compiere as possible, although it seems to merge some additional functionality not yet in Compiere, like Point-Of-Sales system, Manufacturing,... Both are (at least for me) very difficult to grasp. I managed to get them installed, but I never really managed to use them in a way that was useful. Next, I came across TinyERP (which was once mentioned on this very mailing list as a GnuCash alternative for those requiring more business functions). I haven't gotten around to evaluating it yet. And finally I found Intalio. Also very business oriented, also company backed. Same here: I haven't gotten around to really evaluating it. I would be very interested in other's experiences with the above programs. Especially from people that have worked with GnuCash as well. I am by now used to the GnuCash paradigm, so in looking for other solutions I probably tend to look at them with what I have learned in GC. Maybe this mailing list is not the right place for it. Maybe it is as there may be other people like me trying to decide whether GC is the right tool for the job or not. Again, it's not my intention to complain about GnuCash. It's as Derek states: it is targetted at a specific audience. Maybe my company is starting to outgrow Gnucash. In that case, I'd say thank you very much for the great program I have enjoyed for a couple of years before I move on. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Geert Janssens wrote: And I have been looking around, although I didn't migrate yet because of the huge effort it usually takes: there's * Compiere: it does ERP (enterprise resource planning), BPM (Business Project Management) and accounting. It's maintained by a company also called Compiere, the product is open source based, although it seems the company is heading to closing the source. That's why there is now a fork: * Adempiere: this is a fully open source fork of Compiere. It aims to remain as compatible with Compiere as possible, although it seems to merge some additional functionality not yet in Compiere, like Point-Of-Sales system, Manufacturing,... Both are (at least for me) very difficult to grasp. I managed to get them installed, but I never really managed to use them in a way that was useful. I tried to evaluate Compiere, and it failed the stability test - I didn't complete the install before I was running into baffling stacktraces left right and centre. What I am avoiding is the bloated we-try-do-everything software package, that takes forever to learn how to use, forever to fix when it breaks, and forever to pay off the huge bloated computer system required to run it. Instead, I am focusing on finding products that do one thing and do one thing well, and gnucash is an example of a product that does double entry accounting, and does it well. Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. But put it this way, Derek can throw as many tantrums as he likes, we plan to use gnucash to move from a small business to a big business (for now). :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
[[Sorry, this was meant to go on the list as well]] On Tuesday 27 May 2008, you wrote: Gnucash has some bizaare flaws though: gnucash will actively stop you trying to give your customer a refund by refusing to post an invoice with a negative total. In the mean time we hack the XML by hand (!), but once invoice addition is automated, this problem will go away. Heh, I have been bitten by that one too ! I have chosen to keep credit notes (negative invoices) outside of the business tools for that reason. This works, but my credit notes have to do without the added consistency checks done by the business tools. But put it this way, Derek can throw as many tantrums as he likes, we plan to use gnucash to move from a small business to a big business (for now). :) I'd be very interested to hear of your success ! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash automation (was: GDA: Status)
Am Dienstag, 27. Mai 2008 18:05 schrieb Graham Leggett: Derek Atkins wrote: Nope. Not a bug. It's a design decision. It has nothing to do with DB transactions.. Instead it's a question of DB coherency. Basically, it's not supported for a user to modify GnuCash's data store out from under the application. Period. End of discussion. You're welcome to throw as many tantrums as you want on this topic, but that's just the way it is and it's just the way it's going to be for the forseeable future. Sorry. Users needs win I am afraid, if necessary I'll patch gnucash to do it myself. The GnuCash API requires no GUI. Is the API documented anywhere? What the developers here mean by the gnucash API is all the source code that lives in src/engine/, also known as the engine here. Most of it is documented by doxygen comments in the source code. The source code in src/engine depends on glib, but it does not depend on gtk, which should underline the fact that this has nothing to do with GUI issues. The gnucash model of programming expects any non-GUI program to use the programming API that is offered by src/engine in order to open a gnucash data file, extract data from it, potentially modify its content, and maybe save it again. The doxygen comments from source code result in the HTML pages here http://svn.gnucash.org/docs/HEAD/ ; the src/engine/ content is listed here http://svn.gnucash.org/docs/HEAD/group__Engine.html . There was this attempt a few years ago to write a non-GUI gnucash application by separating the qof layer, but it stalled, and IMHO the qof layer was not (yet) the correct layer to build a non-GUI application on. But the API is there and it exists in cleanly separated libraries, so there's no technical reason not to write a non-GUI program that uses src/engine/ for gnucash data file access but none of the GUI stuff. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GDA status
I hit a number of roadblocks. 1) My development machine died 2) After I replaced it, I got myself locked out of gnucash subversion 3) I upgraded to libgda 2.99.5 which introduced a show-stopper bug. I'm now back to 2.99.3 (2.99.4 was very short-lived) and will be able to continue work. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
